Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

functioncmds.c

Blame
    • Robert Haas's avatar
      568d4138
      Use an MVCC snapshot, rather than SnapshotNow, for catalog scans. · 568d4138
      Robert Haas authored
      SnapshotNow scans have the undesirable property that, in the face of
      concurrent updates, the scan can fail to see either the old or the new
      versions of the row.  In many cases, we work around this by requiring
      DDL operations to hold AccessExclusiveLock on the object being
      modified; in some cases, the existing locking is inadequate and random
      failures occur as a result.  This commit doesn't change anything
      related to locking, but will hopefully pave the way to allowing lock
      strength reductions in the future.
      
      The major issue has held us back from making this change in the past
      is that taking an MVCC snapshot is significantly more expensive than
      using a static special snapshot such as SnapshotNow.  However, testing
      of various worst-case scenarios reveals that this problem is not
      severe except under fairly extreme workloads.  To mitigate those
      problems, we avoid retaking the MVCC snapshot for each new scan;
      instead, we take a new snapshot only when invalidation messages have
      been processed.  The catcache machinery already requires that
      invalidation messages be sent before releasing the related heavyweight
      lock; else other backends might rely on locally-cached data rather
      than scanning the catalog at all.  Thus, making snapshot reuse
      dependent on the same guarantees shouldn't break anything that wasn't
      already subtly broken.
      
      Patch by me.  Review by Michael Paquier and Andres Freund.
      568d4138
      History
      Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
      Robert Haas authored
      SnapshotNow scans have the undesirable property that, in the face of
      concurrent updates, the scan can fail to see either the old or the new
      versions of the row.  In many cases, we work around this by requiring
      DDL operations to hold AccessExclusiveLock on the object being
      modified; in some cases, the existing locking is inadequate and random
      failures occur as a result.  This commit doesn't change anything
      related to locking, but will hopefully pave the way to allowing lock
      strength reductions in the future.
      
      The major issue has held us back from making this change in the past
      is that taking an MVCC snapshot is significantly more expensive than
      using a static special snapshot such as SnapshotNow.  However, testing
      of various worst-case scenarios reveals that this problem is not
      severe except under fairly extreme workloads.  To mitigate those
      problems, we avoid retaking the MVCC snapshot for each new scan;
      instead, we take a new snapshot only when invalidation messages have
      been processed.  The catcache machinery already requires that
      invalidation messages be sent before releasing the related heavyweight
      lock; else other backends might rely on locally-cached data rather
      than scanning the catalog at all.  Thus, making snapshot reuse
      dependent on the same guarantees shouldn't break anything that wasn't
      already subtly broken.
      
      Patch by me.  Review by Michael Paquier and Andres Freund.