1. 29 12月, 2010 1 次提交
  2. 28 12月, 2010 11 次提交
  3. 27 12月, 2010 2 次提交
  4. 26 12月, 2010 2 次提交
  5. 25 12月, 2010 4 次提交
  6. 24 12月, 2010 5 次提交
  7. 23 12月, 2010 2 次提交
    • H
      Rewrite the GiST insertion logic so that we don't need the post-recovery · 9de3aa65
      Heikki Linnakangas 提交于
      cleanup stage to finish incomplete inserts or splits anymore. There was two
      reasons for the cleanup step:
      
      1. When a new tuple was inserted to a leaf page, the downlink in the parent
      needed to be updated to contain (ie. to be consistent with) the new key.
      Updating the parent in turn might require recursively updating the parent of
      the parent. We now handle that by updating the parent while traversing down
      the tree, so that when we insert the leaf tuple, all the parents are already
      consistent with the new key, and the tree is consistent at every step.
      
      2. When a page is split, we need to insert the downlink for the new right
      page(s), and update the downlink for the original page to not include keys
      that moved to the right page(s). We now handle that by setting a new flag,
      F_FOLLOW_RIGHT, on the non-rightmost pages in the split. When that flag is
      set, scans always follow the rightlink, regardless of the NSN mechanism used
      to detect concurrent page splits. That way the tree is consistent right after
      split, even though the downlink is still missing. This is very similar to the
      way B-tree splits are handled. When the downlink is inserted in the parent,
      the flag is cleared. To keep the insertion algorithm simple, when an
      insertion sees an incomplete split, indicated by the F_FOLLOW_RIGHT flag, it
      finishes the split before doing anything else.
      
      These changes allow removing the whole "invalid tuple" mechanism, but I
      retained the scan code to still follow invalid tuples correctly. While we
      don't create any such tuples anymore, we want to handle them gracefully in
      case you pg_upgrade a GiST index that has them. If we encounter any on an
      insert, though, we just throw an error saying that you need to REINDEX.
      
      The issue that got me into doing this is that if you did a checkpoint while
      an insert or split was in progress, and the checkpoint finishes quickly so
      that there is no WAL record related to the insert between RedoRecPtr and the
      checkpoint record, recovery from that checkpoint would not know to finish
      the incomplete insert. IOW, we have the same issue we solved with the
      rm_safe_restartpoint mechanism during normal operation too. It's highly
      unlikely to happen in practice, and this fix is far too large to backpatch,
      so we're just going to live with in previous versions, but this refactoring
      fixes it going forward.
      
      With this patch, you don't get the annoying
      'index "FOO" needs VACUUM or REINDEX to finish crash recovery' notices
      anymore if you crash at an unfortunate moment.
      9de3aa65
    • B
      Document that BBU's do not allow partial page writes to be safely turned · 7a1ca897
      Bruce Momjian 提交于
      off unless they guarantee that all writes to the BBU arrive in 8kB chunks.
      
      Per discussion with Greg Smith
      7a1ca897
  8. 22 12月, 2010 5 次提交
  9. 21 12月, 2010 2 次提交
    • R
      Work around unfortunate getppid() behavior on BSD-ish systems. · 24ecde77
      Robert Haas 提交于
      On MacOS X, and apparently also on other BSD-derived systems, attaching
      a debugger causes getppid() to return the pid of the debugging process
      rather than the actual parent PID.  As a result, debugging the
      autovacuum launcher, startup process, or WAL sender on such systems
      causes it to exit, because the previous coding of PostmasterIsAlive()
      detects postmaster death by testing whether getppid() == PostmasterPid.
      
      Work around that behavior by checking the return value of getppid()
      more carefully.  If it's PostmasterPid, the postmaster must be alive;
      if it's 1, assume the postmaster is dead.  If it's any other value,
      assume we've been debugged and fall through to the less-reliable
      kill() test.
      
      Review by Tom Lane.
      24ecde77
    • R
      Allow transactions that don't write WAL to commit asynchronously. · f6a0863e
      Robert Haas 提交于
      This case can arise if a transaction has written data, but only to
      temporary tables.  Loss of the commit record in case of a crash won't
      matter, because the temporary tables will be lost anyway.
      
      Reviewed by Heikki Linnakangas and Simon Riggs.
      f6a0863e
  10. 20 12月, 2010 4 次提交
    • A
      Fix typo · f9e9763b
      Alvaro Herrera 提交于
      Jaime Casanova
      f9e9763b
    • M
      Remove thread dumping constant that requires newer Platform SDK · d382828f
      Magnus Hagander 提交于
      Since we're not multithreaded it only provides marginally useful
      information, and it does require a newer version of the Platform SDK
      than we target. We may want to reconsider this in the future along
      with a fix for MinGW.
      d382828f
    • T
      Fix up handling of simple-form CASE with constant test expression. · 1b19e2c0
      Tom Lane 提交于
      eval_const_expressions() can replace CaseTestExprs with constants when
      the surrounding CASE's test expression is a constant.  This confuses
      ruleutils.c's heuristic for deparsing simple-form CASEs, leading to
      Assert failures or "unexpected CASE WHEN clause" errors.  I had put in
      a hack solution for that years ago (see commit
      514ce7a3 of 2006-10-01), but bug #5794
      from Peter Speck shows that that solution failed to cover all cases.
      
      Fortunately, there's a much better way, which came to me upon reflecting
      that Peter's "CASE TRUE WHEN" seemed pretty redundant: we can "simplify"
      the simple-form CASE to the general form of CASE, by simply omitting the
      constant test expression from the rebuilt CASE construct.  This is
      intuitively valid because there is no need for the executor to evaluate
      the test expression at runtime; it will never be referenced, because any
      CaseTestExprs that would have referenced it are now replaced by constants.
      This won't save a whole lot of cycles, since evaluating a Const is pretty
      cheap, but a cycle saved is a cycle earned.  In any case it beats kluging
      ruleutils.c still further.  So this patch improves const-simplification
      and reverts the previous change in ruleutils.c.
      
      Back-patch to all supported branches.  The bug exists in 8.1 too, but it's
      out of warranty.
      1b19e2c0
    • T
      Fix erroneous parsing of tsquery input "... & !(subexpression) | ..." · abc10262
      Tom Lane 提交于
      After parsing a parenthesized subexpression, we must pop all pending
      ANDs and NOTs off the stack, just like the case for a simple operand.
      Per bug #5793.
      
      Also fix clones of this routine in contrib/intarray and contrib/ltree,
      where input of types query_int and ltxtquery had the same problem.
      
      Back-patch to all supported versions.
      abc10262
  11. 19 12月, 2010 2 次提交