diff options
author | Tom Lane | 2010-02-07 20:48:13 +0000 |
---|---|---|
committer | Tom Lane | 2010-02-07 20:48:13 +0000 |
commit | b9b8831ad60f6e4bd580fe6dbe9749359298a3c4 (patch) | |
tree | af6948498f13a43edd982b05808ed89b5b8191ab /src/include/storage/sinval.h | |
parent | 7fc30c488fc6e9674564206193c29b1a657a818f (diff) |
Create a "relation mapping" infrastructure to support changing the relfilenodes
of shared or nailed system catalogs. This has two key benefits:
* The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs.
* We no longer have to use an unsafe reindex-in-place approach for reindexing
shared catalogs.
CLUSTER on nailed catalogs now works too, although I left it disabled on
shared catalogs because the resulting pg_index.indisclustered update would
only be visible in one database.
Since reindexing shared system catalogs is now fully transactional and
crash-safe, the former special cases in REINDEX behavior have been removed;
shared catalogs are treated the same as non-shared.
This commit does not do anything about the recently-discussed problem of
deadlocks between VACUUM FULL/CLUSTER on a system catalog and other
concurrent queries; will address that in a separate patch. As a stopgap,
parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid
such failures during the regression tests.
Diffstat (limited to 'src/include/storage/sinval.h')
-rw-r--r-- | src/include/storage/sinval.h | 53 |
1 files changed, 42 insertions, 11 deletions
diff --git a/src/include/storage/sinval.h b/src/include/storage/sinval.h index 9f7bb2b2eea..bad8f505427 100644 --- a/src/include/storage/sinval.h +++ b/src/include/storage/sinval.h @@ -7,7 +7,7 @@ * Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/include/storage/sinval.h,v 1.56 2010/01/09 16:49:27 sriggs Exp $ + * $PostgreSQL: pgsql/src/include/storage/sinval.h,v 1.57 2010/02/07 20:48:13 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -19,14 +19,16 @@ /* - * We currently support three types of shared-invalidation messages: one that - * invalidates an entry in a catcache, one that invalidates a relcache entry, - * and one that invalidates an smgr cache entry. More types could be added - * if needed. The message type is identified by the first "int16" field of - * the message struct. Zero or positive means a catcache inval message (and - * also serves as the catcache ID field). -1 means a relcache inval message. - * -2 means an smgr inval message. Other negative values are available to - * identify other inval message types. + * We support several types of shared-invalidation messages: + * * invalidate a specific tuple in a specific catcache + * * invalidate all catcache entries from a given system catalog + * * invalidate a relcache entry for a specific logical relation + * * invalidate an smgr cache entry for a specific physical relation + * * invalidate the mapped-relation mapping for a given database + * More types could be added if needed. The message type is identified by + * the first "int16" field of the message struct. Zero or positive means a + * specific-catcache inval message (and also serves as the catcache ID field). + * Negative values identify the other message types, as per codes below. * * Catcache inval events are initially driven by detecting tuple inserts, * updates and deletions in system catalogs (see CacheInvalidateHeapTuple). @@ -46,6 +48,16 @@ * and so that negative cache entries can be recognized with good accuracy. * (Of course this assumes that all the backends are using identical hashing * code, but that should be OK.) + * + * Catcache and relcache invalidations are transactional, and so are sent + * to other backends upon commit. Internally to the generating backend, + * they are also processed at CommandCounterIncrement so that later commands + * in the same transaction see the new state. The generating backend also + * has to process them at abort, to flush out any cache state it's loaded + * from no-longer-valid entries. + * + * smgr and relation mapping invalidations are non-transactional: they are + * sent immediately when the underlying file change is made. */ typedef struct @@ -57,7 +69,16 @@ typedef struct uint32 hashValue; /* hash value of key for this catcache */ } SharedInvalCatcacheMsg; -#define SHAREDINVALRELCACHE_ID (-1) +#define SHAREDINVALCATALOG_ID (-1) + +typedef struct +{ + int16 id; /* type field --- must be first */ + Oid dbId; /* database ID, or 0 if a shared catalog */ + Oid catId; /* ID of catalog whose contents are invalid */ +} SharedInvalCatalogMsg; + +#define SHAREDINVALRELCACHE_ID (-2) typedef struct { @@ -66,7 +87,7 @@ typedef struct Oid relId; /* relation ID */ } SharedInvalRelcacheMsg; -#define SHAREDINVALSMGR_ID (-2) +#define SHAREDINVALSMGR_ID (-3) typedef struct { @@ -74,12 +95,22 @@ typedef struct RelFileNode rnode; /* physical file ID */ } SharedInvalSmgrMsg; +#define SHAREDINVALRELMAP_ID (-4) + +typedef struct +{ + int16 id; /* type field --- must be first */ + Oid dbId; /* database ID, or 0 for shared catalogs */ +} SharedInvalRelmapMsg; + typedef union { int16 id; /* type field --- must be first */ SharedInvalCatcacheMsg cc; + SharedInvalCatalogMsg cat; SharedInvalRelcacheMsg rc; SharedInvalSmgrMsg sm; + SharedInvalRelmapMsg rm; } SharedInvalidationMessage; |