1. 16 May, 2011 5 commits
  2. 15 May, 2011 3 commits
  3. 13 May, 2011 1 commit
  4. 12 May, 2011 3 commits
    • Robert Haas's avatar
      Kill stray "not". · c5ab8425
      Robert Haas authored
      c5ab8425
    • Tom Lane's avatar
      Fix write-past-buffer-end in ldapServiceLookup(). · 8d0df204
      Tom Lane authored
      The code to assemble ldap_get_values_len's output into a single string
      wrote the terminating null one byte past where it should.  Fix that,
      and make some other cosmetic adjustments to make the code a trifle more
      readable and more in line with usual Postgres coding style.
      
      Also, free the "result" string when done with it, to avoid a permanent
      memory leak.
      
      Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
      8d0df204
    • Alvaro Herrera's avatar
      Fix assorted typos · c6eb5740
      Alvaro Herrera authored
      c6eb5740
  5. 11 May, 2011 6 commits
    • Tom Lane's avatar
      Split PGC_S_DEFAULT into two values, for true boot_val vs computed default. · e05b8664
      Tom Lane authored
      Failure to distinguish these cases is the real cause behind the recent
      reports of Windows builds crashing on 'infinity'::timestamp, which was
      directly due to failure to establish a value of timezone_abbreviations
      in postmaster child processes.  The postmaster had the desired value,
      but write_one_nondefault_variable() didn't transmit it to backends.
      
      To fix that, invent a new value PGC_S_DYNAMIC_DEFAULT, and be sure to use
      that or PGC_S_ENV_VAR (as appropriate) for "default" settings that are
      computed during initialization.  (We need both because there's at least
      one variable that could receive a value from either source.)
      
      This commit also fixes ProcessConfigFile's failure to restore the correct
      default value for certain GUC variables if they are set in postgresql.conf
      and then removed/commented out of the file.  We have to recompute and
      reinstall the value for any GUC variable that could have received a value
      from PGC_S_DYNAMIC_DEFAULT or PGC_S_ENV_VAR sources, and there were a
      number of oversights.  (That whole thing is a crock that needs to be
      redesigned, but not today.)
      
      However, I intentionally didn't make it work "exactly right" for the cases
      of timezone and log_timezone.  The exactly right behavior would involve
      running select_default_timezone, which we'd have to do independently in
      each postgres process, causing the whole database to become entirely
      unresponsive for as much as several seconds.  That didn't seem like a good
      idea, especially since the variable's removal from postgresql.conf might be
      just an accidental edit.  Instead the behavior is to adopt the previously
      active setting as if it were default.
      
      Note that this patch creates an ABI break for extensions that use any of
      the PGC_S_XXX constants; they'll need to be recompiled.
      e05b8664
    • Tom Lane's avatar
      Clean up parsing of CREATE TRIGGER's argument list. · 6fc6686b
      Tom Lane authored
      Use ColLabel in place of ColId, so that reserved words are accepted as if
      they were not reserved.  Also, remove BCONST and XCONST, which were never
      documented as allowed.  Allowing those exposes to users an implementation
      detail, namely the format in which the lexer outputs such constants, that
      seems unwise to expose.
      
      No documentation change needed, since this just makes the code act more
      like you'd expect from reading the CREATE TRIGGER man page.
      
      Per complaint from Szymon Guz and subsequent discussion.
      6fc6686b
    • Heikki Linnakangas's avatar
      Shut down WAL receiver if it's still running at end of recovery. We used to · a0c85141
      Heikki Linnakangas authored
      just check that it's not running and PANIC if it was, but that can rightfully
      happen if recovery stops at recovery target.
      a0c85141
    • Tom Lane's avatar
    • Bruce Momjian's avatar
    • Tom Lane's avatar
      Prevent datebsearch() from crashing on base == NULL && nel == 0. · 2e82d0b3
      Tom Lane authored
      Normally nel == 0 works okay because the initial value of "last" will be
      less than "base"; but if "base" is zero then the calculation wraps around
      and we have a very large (unsigned) value for "last", so that the loop can
      be entered and we get a SIGSEGV on a bogus pointer.
      
      This is certainly the proximate cause of the recent reports of Windows
      builds crashing on 'infinity'::timestamp --- evidently, they're either not
      setting an active timezonetktbl, or setting an empty one.  It's not yet
      clear to me why it's only happening on Windows and not happening on any
      buildfarm member.  But even if that's due to some bug elsewhere, it seems
      wise for this function to not choke on the powerup values of
      timezonetktbl/sztimezonetktbl.
      
      I also changed the copy of this code in ecpglib, although I am not sure
      whether it's exposed to a similar hazard.
      
      Per report and stack trace from Richard Broersma.
      2e82d0b3
  6. 10 May, 2011 12 commits
  7. 09 May, 2011 3 commits
  8. 08 May, 2011 3 commits
  9. 07 May, 2011 4 commits