1. 18 3月, 2007 4 次提交
  2. 17 3月, 2007 9 次提交
  3. 16 3月, 2007 4 次提交
    • A
      Fix uninitialized value in pgstatindex leading to invalid values being · c9d3b8f5
      Alvaro Herrera 提交于
      reported in some cases.  Report and patch from Tatsuhito Kasahara.
      
      Also fix a couple of other bugs I noticed in skimming the surrounding code.
      c9d3b8f5
    • A
      · f6e3313f
      Andrew Dunstan 提交于
      Remove undocumented support for copy syntax from before 7.3. Update comments to
      reflect syntax actually supported, e.g. by including CSV params.
      f6e3313f
    • M
      Show aggregate return types in psql \da output. · 348b6218
      Magnus Hagander 提交于
      Greg Sabino Mullane
      348b6218
    • T
      Make use of plancache module for SPI plans. In particular, since plpgsql · 95f6d2d2
      Tom Lane 提交于
      uses SPI plans, this finally fixes the ancient gotcha that you can't
      drop and recreate a temp table used by a plpgsql function.
      
      Along the way, clean up SPI's API a little bit by declaring SPI plan
      pointers as "SPIPlanPtr" instead of "void *".  This is cosmetic but
      helps to forestall simple programming mistakes.  (I have changed some
      but not all of the callers to match; there are still some "void *"'s
      in contrib and the PL's.  This is intentional so that we can see if
      anyone's compiler complains about it.)
      95f6d2d2
  4. 15 3月, 2007 2 次提交
    • T
      Fix a longstanding bug in VACUUM FULL's handling of update chains. The code · d3ff1801
      Tom Lane 提交于
      did not expect that a DEAD tuple could follow a RECENTLY_DEAD tuple in an
      update chain, but because the OldestXmin rule for determining deadness is a
      simplification of reality, it is possible for this situation to occur
      (implying that the RECENTLY_DEAD tuple is in fact dead to all observers,
      but this patch does not attempt to exploit that).  The code would follow a
      chain forward all the way, but then stop before a DEAD tuple when backing
      up, meaning that not all of the chain got moved.  This could lead to copying
      the chain multiple times (resulting in duplicate copies of the live tuple at
      its end), or leaving dangling index entries behind (which, aside from
      generating warnings from later vacuums, creates a risk of wrong query
      results or bogus duplicate-key errors once the heap slot the index entry
      points to is repopulated).
      
      The fix is to recheck HeapTupleSatisfiesVacuum while following a chain
      forward, and to stop if a DEAD tuple is reached.  Each contiguous group
      of RECENTLY_DEAD tuples will therefore be copied as a separate chain.
      The patch also adds a couple of extra sanity checks to verify correct
      behavior.
      
      Per report and test case from Pavan Deolasee.
      d3ff1801
    • T
      Arrange to install a "posixrules" entry in our timezone database, so that · 0169c354
      Tom Lane 提交于
      POSIX-style timezone specs that don't exactly match any database entry will
      be treated as having correct USA DST rules.  Also, document that this can
      be changed if you want to use some other DST rules with a POSIX zone spec.
      
      We could consider changing localtime.c's TZDEFRULESTRING, but since that
      facility can only deal with one DST transition rule, it seems fairly useless
      now; might as well just plan to override it using a "posixrules" entry.
      
      Backpatch as far as 8.0.  There isn't much we can do in 7.x ... either your
      libc gets it right, or it doesn't.
      0169c354
  5. 14 3月, 2007 6 次提交
  6. 13 3月, 2007 8 次提交
  7. 11 3月, 2007 1 次提交
  8. 10 3月, 2007 1 次提交
  9. 09 3月, 2007 2 次提交
  10. 08 3月, 2007 1 次提交
  11. 07 3月, 2007 2 次提交
    • A
      Cleanup the bootstrap code a little, and rename "dummy procs" in the code · 626eb021
      Alvaro Herrera 提交于
      comments and variables to "auxiliary proc", per Heikki's request.
      626eb021
    • T
      Fix oversight in original coding of inline_function(): since · cc0cac4a
      Tom Lane 提交于
      check_sql_fn_retval allows binary-compatibility cases, the expression
      extracted from an inline-able SQL function might have a type that is only
      binary-compatible with the declared function result type.  To avoid possibly
      changing the semantics of the expression, we should insert a RelabelType node
      in such cases.  This has only been shown to have bad consequences in recent
      8.1 and up releases, but I suspect there may be failure cases in the older
      branches too, so patch it all the way back.  Per bug #3116 from Greg Mullane.
      
      Along the way, fix an omission in eval_const_expressions_mutator: it failed
      to copy the relabelformat field when processing a RelabelType.  No known
      observable failures from this, but it definitely isn't intended behavior.
      cc0cac4a