1. 08 10月, 2013 3 次提交
    • R
      Make DISCARD SEQUENCES also discard the last used sequence. · 16a906f5
      Robert Haas 提交于
      Otherwise, we access already-freed memory.  Oops.
      
      Report by Michael Paquier.  Fix by me.
      16a906f5
    • R
      plpgsql: Add new option print_strict_params. · 689746c0
      Robert Haas 提交于
      This option provides more detailed error messages when STRICT is used
      and the number of rows returned is not one.
      
      Marko Tiikkaja, reviewed by Ian Lawrence Barwick
      689746c0
    • K
      Eliminate xmin from hash tag for predicate locks on heap tuples. · c01262a8
      Kevin Grittner 提交于
      If a tuple was frozen while its predicate locks mattered,
      read-write dependencies could be missed, resulting in failure to
      detect conflicts which could lead to anomalies in committed
      serializable transactions.
      
      This field was added to the tag when we still thought that it was
      necessary to carry locks forward to a new version of an updated
      row.  That was later proven to be unnecessary, which allowed
      simplification of the code, but elimination of xmin from the tag
      was missed at the time.
      
      Per report and analysis by Heikki Linnakangas.
      Backpatch to 9.1.
      c01262a8
  2. 07 10月, 2013 1 次提交
  3. 06 10月, 2013 4 次提交
    • N
      pgbench: Comment on thread timing hazards. · 7db0dc0e
      Noah Misch 提交于
      Reviewed by Fabien COELHO.
      7db0dc0e
    • A
      Fix various bugs in postmaster SIGKILL processing · bf261798
      Alvaro Herrera 提交于
      Clamp the minimum sleep time during immediate shutdown or crash to a
      minimum of zero, not a maximum of one second.  The previous code could
      result in a negative sleep time, leading to failure in select() calls.
      
      Also, on crash recovery, reset AbortStartTime as soon as SIGKILL is sent
      or abort processing has commenced instead of waiting until the startup
      process completes.  Reset AbortStartTime as soon as SIGKILL is sent,
      too, to avoid doing that repeatedly.
      
      Per trouble report from Jeff Janes on
      CAMkU=1xd3=wFqZwwuXPWe4BQs3h1seYo8LV9JtSjW5RodoPxMg@mail.gmail.com
      
      Author: MauMau
      bf261798
    • N
      pgbench: Elaborate latency reporting. · 2d6c0f10
      Noah Misch 提交于
      Isolate transaction latency (elapsed time between submitting first
      command and receiving response to last command) from client-side delays
      pertaining to the --rate schedule.  Under --rate, report schedule lag as
      defined in the documentation.  Report latency standard deviation
      whenever we collect the measurements to do so.  All of these changes
      affect --progress messages and the final report.
      
      Fabien COELHO, reviewed by Pavel Stehule.
      2d6c0f10
    • N
      pgbench: Remove stray use of "float" math. · 8e00a385
      Noah Misch 提交于
      Oversight in commit 4a87f308.
      
      Fabien COELHO
      8e00a385
  4. 05 10月, 2013 5 次提交
  5. 04 10月, 2013 4 次提交
  6. 03 10月, 2013 4 次提交
  7. 02 10月, 2013 4 次提交
  8. 30 9月, 2013 8 次提交
  9. 27 9月, 2013 2 次提交
  10. 26 9月, 2013 2 次提交
    • H
      Fix spurious warning after vacuuming a page on a table with no indexes. · adaba275
      Heikki Linnakangas 提交于
      There is a rare race condition, when a transaction that inserted a tuple
      aborts while vacuum is processing the page containing the inserted tuple.
      Vacuum prunes the page first, which normally removes any dead tuples, but
      if the inserting transaction aborts right after that, the loop after
      pruning will see a dead tuple and remove it instead. That's OK, but if the
      page is on a table with no indexes, and the page becomes completely empty
      after removing the dead tuple (or tuples) on it, it will be immediately
      marked as all-visible. That's OK, but the sanity check in vacuum would
      throw a warning because it thinks that the page contains dead tuples and
      was nevertheless marked as all-visible, even though it just vacuumed away
      the dead tuples and so it doesn't actually contain any.
      
      Spotted this while reading the code. It's difficult to hit the race
      condition otherwise, but can be done by putting a breakpoint after the
      heap_page_prune() call.
      
      Backpatch all the way to 8.4, where this code first appeared.
      adaba275
    • N
      pgbench: Correct for bias in --rate schedule generation. · c2df45a3
      Noah Misch 提交于
      Previous code gave a mean delay 0.44% below target.  This change also
      has the effect of increasing the maximum possible delay.
      
      Fabien COELHO
      c2df45a3
  11. 25 9月, 2013 2 次提交
  12. 24 9月, 2013 1 次提交