diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2013-01-18 18:06:20 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2013-01-18 18:06:20 -0500 |
commit | c2a14bc7c994065edcc48183913a1fae2af27990 (patch) | |
tree | 861568bdf9f37ca8f2cc011ec3b8ea522f696124 /src/tutorial/syscat.source | |
parent | 530bbfac57c8c5df9d38754759d95f1588c427f7 (diff) | |
download | postgresql-c2a14bc7c994065edcc48183913a1fae2af27990.tar.gz postgresql-c2a14bc7c994065edcc48183913a1fae2af27990.zip |
Protect against SnapshotNow race conditions in pg_tablespace scans.
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
Diffstat (limited to 'src/tutorial/syscat.source')
0 files changed, 0 insertions, 0 deletions