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

dbcommands.c

  • Tom Lane's avatar
    c2a14bc7
    Protect against SnapshotNow race conditions in pg_tablespace scans. · c2a14bc7
    Tom Lane authored
    Use of SnapshotNow is known to expose us to race conditions if the tuple(s)
    being sought could be updated by concurrently-committing transactions.
    CREATE DATABASE and DROP DATABASE are particularly exposed because they do
    heavyweight filesystem operations during their scans of pg_tablespace,
    so that the scans run for a very long time compared to most.  Furthermore,
    the potential consequences of a missed or twice-visited row are nastier
    than average:
    
    * createdb() could fail with a bogus "file already exists" error, or
      silently fail to copy one or more tablespace's worth of files into the
      new database.
    
    * remove_dbtablespaces() could miss one or more tablespaces, thus failing
      to free filesystem space for the dropped database.
    
    * check_db_file_conflict() could likewise miss a tablespace, leading to an
      OID conflict that could result in data loss either immediately or in
      future operations.  (This seems of very low probability, though, since a
      duplicate database OID would be unlikely to start with.)
    
    Hence, it seems worth fixing these three places to use MVCC snapshots, even
    though this will someday be superseded by a generic solution to SnapshotNow
    race conditions.
    
    Back-patch to all active branches.
    
    Stephen Frost and Tom Lane
    c2a14bc7
    History
    Protect against SnapshotNow race conditions in pg_tablespace scans.
    Tom Lane authored
    Use of SnapshotNow is known to expose us to race conditions if the tuple(s)
    being sought could be updated by concurrently-committing transactions.
    CREATE DATABASE and DROP DATABASE are particularly exposed because they do
    heavyweight filesystem operations during their scans of pg_tablespace,
    so that the scans run for a very long time compared to most.  Furthermore,
    the potential consequences of a missed or twice-visited row are nastier
    than average:
    
    * createdb() could fail with a bogus "file already exists" error, or
      silently fail to copy one or more tablespace's worth of files into the
      new database.
    
    * remove_dbtablespaces() could miss one or more tablespaces, thus failing
      to free filesystem space for the dropped database.
    
    * check_db_file_conflict() could likewise miss a tablespace, leading to an
      OID conflict that could result in data loss either immediately or in
      future operations.  (This seems of very low probability, though, since a
      duplicate database OID would be unlikely to start with.)
    
    Hence, it seems worth fixing these three places to use MVCC snapshots, even
    though this will someday be superseded by a generic solution to SnapshotNow
    race conditions.
    
    Back-patch to all active branches.
    
    Stephen Frost and Tom Lane