1. 22 8月, 2011 2 次提交
  2. 21 8月, 2011 2 次提交
    • B
      Have thread_test create its test files in the current directory, rather · 6cc08e70
      Bruce Momjian 提交于
      than /tmp.  Also cleanup C defines and add comments.
      
      Per report by Alex Soto
      6cc08e70
    • T
      Fix performance problem when building a lossy tidbitmap. · 08e1eedf
      Tom Lane 提交于
      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
  3. 20 8月, 2011 7 次提交
  4. 19 8月, 2011 3 次提交
  5. 18 8月, 2011 10 次提交
  6. 17 8月, 2011 12 次提交
    • A
      Properly handle empty arrays returned from plperl functions. · 68c903a6
      Andrew Dunstan 提交于
      Bug reported by David Wheeler, fix by Alex Hunsaker.
      68c903a6
    • P
      Translation updates · 1bf80041
      Peter Eisentraut 提交于
      1bf80041
    • H
      a1a847d3
    • H
      Fix comment about which version had BACKUP METHOD line in backup_lable, again. · 1d0392b2
      Heikki Linnakangas 提交于
      It was invalidated again by Fujii's patch to 9.1.
      1d0392b2
    • M
      Adjust wording now that estimated size can increase · e5cb7563
      Magnus Hagander 提交于
      Per comment form Fujii Masao.
      e5cb7563
    • P
      Move \r out of translatable strings · 7f699804
      Peter Eisentraut 提交于
      The translation tools are very unhappy about seeing \r in translatable
      strings, so move it to a separate fprintf call.
      7f699804
    • P
      MacOS -> Mac OS · 13684090
      Peter Eisentraut 提交于
      Josh Kupershmidt
      13684090
    • T
      Revise sinval code to remove no-longer-used tuple TID from inval messages. · b5282aa8
      Tom Lane 提交于
      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
    • T
      Forget about targeting catalog cache invalidations by tuple TID. · 632ae682
      Tom Lane 提交于
      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
    • T
      Fix incorrect order of operations during sinval reset processing. · f4d7f1ad
      Tom Lane 提交于
      We have to be sure that we have revalidated each nailed-in-cache relcache
      entry before we try to use it to load data for some other relcache entry.
      The introduction of "mapped relations" in 9.0 broke this, because although
      we updated the state kept in relmapper.c early enough, we failed to
      propagate that information into relcache entries soon enough; in
      particular, we could try to fetch pg_class rows out of pg_class before
      we'd updated its relcache entry's rd_node.relNode value from the map.
      
      This bug accounts for Dave Gould's report of failures after "vacuum full
      pg_class", and I believe that there is risk for other system catalogs
      as well.
      
      The core part of the fix is to copy relmapper data into the relcache
      entries during "phase 1" in RelationCacheInvalidate(), before they'll be
      used in "phase 2".  To try to future-proof the code against other similar
      bugs, I also rearranged the order in which nailed relations are visited
      during phase 2: now it's pg_class first, then pg_class_oid_index, then
      other nailed relations.  This should ensure that RelationClearRelation can
      apply RelationReloadIndexInfo to all nailed indexes without risking use
      of not-yet-revalidated relcache entries.
      
      Back-patch to 9.0 where the relation mapper was introduced.
      f4d7f1ad
    • T
      Preserve toast value OIDs in toast-swap-by-content for CLUSTER/VACUUM FULL. · 7b0d0e93
      Tom Lane 提交于
      This works around the problem that a catalog cache entry might contain a
      toast pointer that we try to dereference just as a VACUUM FULL completes
      on that catalog.  We will see the sinval message on the cache entry when
      we acquire lock on the toast table, but by that point we've already told
      tuptoaster.c "here's the pointer to fetch", so it's difficult from a code
      structural standpoint to update the pointer before we use it.  Much less
      painful to ensure that toast pointers are not invalidated in the first
      place.  We have to add a bit of code to deal with the case that a value
      that previously wasn't toasted becomes so; but that should be a
      seldom-exercised corner case, so the inefficiency shouldn't be significant.
      
      Back-patch to 9.0.  In prior versions, we didn't allow CLUSTER on system
      catalogs, and VACUUM FULL didn't result in reassignment of toast OIDs, so
      there was no problem.
      7b0d0e93
    • T
      Fix race condition in relcache init file invalidation. · 2ada6779
      Tom Lane 提交于
      The previous code tried to synchronize by unlinking the init file twice,
      but that doesn't actually work: it leaves a window wherein a third process
      could read the already-stale init file but miss the SI messages that would
      tell it the data is stale.  The result would be bizarre failures in catalog
      accesses, typically "could not read block 0 in file ..." later during
      startup.
      
      Instead, hold RelCacheInitLock across both the unlink and the sending of
      the SI messages.  This is more straightforward, and might even be a bit
      faster since only one unlink call is needed.
      
      This has been wrong since it was put in (in 2002!), so back-patch to all
      supported releases.
      2ada6779
  7. 16 8月, 2011 4 次提交