diff options
| author | Robert Haas <rhaas@postgresql.org> | 2013-07-02 09:47:01 -0400 |
|---|---|---|
| committer | Robert Haas <rhaas@postgresql.org> | 2013-07-02 09:47:01 -0400 |
| commit | 568d4138c646cd7cd8a837ac244ef2caf27c6bb8 (patch) | |
| tree | 82022e9bd58a217976f94fea942f24b0c40278c0 /src/backend/utils/adt/dbsize.c | |
| parent | 384f933046dc9e9a2b416f5f7b3be30b93587c63 (diff) | |
| download | postgresql-568d4138c646cd7cd8a837ac244ef2caf27c6bb8.tar.gz postgresql-568d4138c646cd7cd8a837ac244ef2caf27c6bb8.zip | |
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
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.
Diffstat (limited to 'src/backend/utils/adt/dbsize.c')
| -rw-r--r-- | src/backend/utils/adt/dbsize.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/utils/adt/dbsize.c b/src/backend/utils/adt/dbsize.c index 4c4e1ed8202..5ddeffe4820 100644 --- a/src/backend/utils/adt/dbsize.c +++ b/src/backend/utils/adt/dbsize.c @@ -697,7 +697,7 @@ pg_size_pretty_numeric(PG_FUNCTION_ARGS) * That leads to a couple of choices. We work from the pg_class row alone * rather than actually opening each relation, for efficiency. We don't * fail if we can't find the relation --- some rows might be visible in - * the query's MVCC snapshot but already dead according to SnapshotNow. + * the query's MVCC snapshot even though the relations have been dropped. * (Note: we could avoid using the catcache, but there's little point * because the relation mapper also works "in the now".) We also don't * fail if the relation doesn't have storage. In all these cases it |