1. 11 May, 2011 5 commits
    • 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
  2. 10 May, 2011 12 commits
  3. 09 May, 2011 3 commits
  4. 08 May, 2011 3 commits
  5. 07 May, 2011 6 commits
  6. 06 May, 2011 3 commits
    • Peter Eisentraut's avatar
      Improve compiler string shown in version() · 8dd2ede3
      Peter Eisentraut authored
      With some compilers such as Clang and ICC emulating GCC, using a
      version string of the form "GCC $version" can be quite misleading.
      Also, a great while ago, the version output from gcc --version started
      including the string "gcc", so it is redundant to repeat that.  In
      order to support ancient GCC versions, we now prefix the result with
      "GCC " only if the version output does not start with a letter.
      8dd2ede3
    • Tom Lane's avatar
      Move RegisterPredicateLockingXid() call to a safer place. · d2088ae9
      Tom Lane authored
      The SSI patch inserted a call of RegisterPredicateLockingXid into
      GetNewTransactionId, which was a bad idea on a couple of grounds.  First,
      it's not necessary to hold XidGenLock while manipulating that shared
      memory, and doing so is bad because XidGenLock is a high-contention lock
      that should be held for as short a time as possible.  (Not to mention that
      it adds an entirely unnecessary deadlock hazard, since we must take
      SerializableXactHashLock as well.)  Second, the specific place where it was
      put was between extending CLOG and advancing nextXid, which could result in
      unpleasant behavior in case of a failure there.  Pull the call out to
      AssignTransactionId, which is much safer and arguably better from a
      modularity standpoint too.
      
      There is more work to do to clean up the failure-before-advancing-nextXid
      issue, but that is a separate change that will need to be back-patched.
      So for the moment I just want to make GetNewTransactionId look the same as
      it did in prior versions.
      d2088ae9
    • Tom Lane's avatar
      Remove precedence labeling of keywords TRUE, FALSE, UNKNOWN, and ZONE. · 12b71645
      Tom Lane authored
      These were labeled with precedences just to avoid attaching explicit
      precedences to the productions in which they were the last terminal symbol.
      Since a terminal symbol precedence marking can affect many other things
      too, it seems like better practice to attach precedence labels to the
      productions, and not mark the terminal symbols.
      
      Ideally we'd also remove the precedence attached to NULL_P, but it turns
      out that we are actually depending on that having a precedence higher than
      POSTFIXOP, else we get a shift/reduce conflict for postfix operators in
      b_expr.  (Which more or less proves my point about these markings having a
      high risk of unexpected consequences.)  For the moment, move NULL_P into
      the set of keywords grouped with IDENT, so that at least it will act
      similarly to non-keywords; and document the interaction.
      12b71645
  7. 05 May, 2011 5 commits
  8. 04 May, 2011 3 commits