1. 09 Dec, 2007 1 commit
  2. 08 Dec, 2007 2 commits
  3. 07 Dec, 2007 7 commits
  4. 06 Dec, 2007 4 commits
  5. 05 Dec, 2007 1 commit
  6. 04 Dec, 2007 2 commits
  7. 03 Dec, 2007 12 commits
  8. 02 Dec, 2007 6 commits
  9. 01 Dec, 2007 4 commits
  10. 30 Nov, 2007 1 commit
    • Tom Lane's avatar
      Avoid incrementing the CommandCounter when CommandCounterIncrement is called · 895a94de
      Tom Lane authored
      but no database changes have been made since the last CommandCounterIncrement.
      This should result in a significant improvement in the number of "commands"
      that can typically be performed within a transaction before hitting the 2^32
      CommandId size limit.  In particular this buys back (and more) the possible
      adverse consequences of my previous patch to fix plan caching behavior.
      
      The implementation requires tracking whether the current CommandCounter
      value has been "used" to mark any tuples.  CommandCounter values stored into
      snapshots are presumed not to be used for this purpose.  This requires some
      small executor changes, since the executor used to conflate the curcid of
      the snapshot it was using with the command ID to mark output tuples with.
      Separating these concepts allows some small simplifications in executor APIs.
      
      Something for the TODO list: look into having CommandCounterIncrement not do
      AcceptInvalidationMessages.  It seems fairly bogus to be doing it there,
      but exactly where to do it instead isn't clear, and I'm disinclined to mess
      with asynchronous behavior during late beta.
      895a94de