1. 23 Aug, 2011 4 commits
  2. 22 Aug, 2011 4 commits
  3. 21 Aug, 2011 1 commit
    • Tom Lane's avatar
      Fix trigger WHEN conditions when both BEFORE and AFTER triggers exist. · b33f78df
      Tom Lane authored
      Due to tuple-slot mismanagement, evaluation of WHEN conditions for AFTER
      ROW UPDATE triggers could crash if there had been a BEFORE ROW trigger
      fired for the same update.  Fix by not trying to overload the use of
      estate->es_trig_tuple_slot.  Per report from Yoran Heling.
      
      Back-patch to 9.0, when trigger WHEN conditions were introduced.
      b33f78df
  4. 20 Aug, 2011 2 commits
    • Bruce Momjian's avatar
      Have thread_test create its test files in the current directory, rather · 6cc08e70
      Bruce Momjian authored
      than /tmp.  Also cleanup C defines and add comments.
      
      Per report by Alex Soto
      6cc08e70
    • Tom Lane's avatar
      Fix performance problem when building a lossy tidbitmap. · 08e1eedf
      Tom Lane authored
      As pointed out by Sergey Koposov, repeated invocations of tbm_lossify can
      make building a large tidbitmap into an O(N^2) operation.  To fix, make
      sure we remove more than the minimum amount of information per call, and
      add a fallback path to behave sanely if we're unable to fit the bitmap
      within the requested amount of memory.
      
      This has been wrong since the tidbitmap code was written, so back-patch
      to all supported branches.
      08e1eedf
  5. 19 Aug, 2011 9 commits
  6. 18 Aug, 2011 10 commits
  7. 17 Aug, 2011 8 commits
  8. 16 Aug, 2011 2 commits
    • Tom Lane's avatar
      Revise sinval code to remove no-longer-used tuple TID from inval messages. · b5282aa8
      Tom Lane authored
      This requires adjusting the API for syscache callback functions: they now
      get a hash value, not a TID, to identify the target tuple.  Most of them
      weren't paying any attention to that argument anyway, but plancache did
      require a small amount of fixing.
      
      Also, improve performance a trifle by avoiding sending duplicate inval
      messages when a heap_update isn't changing the catcache lookup columns.
      b5282aa8
    • Tom Lane's avatar
      Forget about targeting catalog cache invalidations by tuple TID. · 632ae682
      Tom Lane authored
      The TID isn't stable enough: we might queue an sinval event before a VACUUM
      FULL, and then process it afterwards, when the target tuple no longer has
      the same TID.  So we must invalidate entries on the basis of hash value
      only.  The old coding can be shown to result in various bizarre,
      hard-to-reproduce errors in the presence of concurrent VACUUM FULLs on
      system catalogs, and could easily result in permanent catalog corruption,
      up to and including complete loss of tables.
      
      This commit is just a minimal fix that removes the unsafe comparison.
      We should remove transmission of the tuple TID from sinval messages
      altogether, and then arrange to suppress the extra message in the common
      case of a heap_update that doesn't change the key hashvalue.  But that's
      going to be much more invasive, and will only produce a probably-marginal
      performance gain, so it doesn't seem like material for a back-patch.
      
      Back-patch to 9.0.  Before that, VACUUM FULL refused to do any tuple moving
      if it found any INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples (and
      CLUSTER would give up altogether), so there was no risk of moving a tuple
      that might be the subject of an unsent sinval message.
      632ae682