Clean up some longstanding problems in shared-cache invalidation.

SI messages now include the relevant database OID, so that operations
in one database do not cause useless cache flushes in backends attached
to other databases.  Declare SI messages properly using a union, to
eliminate the former assumption that Oid is the same size as int or Index.
Rewrite the nearly-unreadable code in inval.c, and document it better.
Arrange for catcache flushes at end of command/transaction to happen before
relcache flushes do --- this avoids loading a new tuple into the catcache
while setting up new relcache entry, only to have it be flushed again
immediately.

1 files changed, 51 insertions, 5 deletions

diff --git a/src/include/storage/sinval.h b/src/include/storage/sinval.h
index 93a10e72feb..7d43c645780 100644
--- a/src/include/storage/sinval.h
+++ b/src/include/storage/sinval.h
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $Id: sinval.h,v 1.18 2001/02/26 00:50:08 tgl Exp $
+ * $Id: sinval.h,v 1.19 2001/06/19 19:42:16 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -17,15 +17,61 @@
 #include "storage/itemptr.h"
 #include "storage/spin.h"
 
+
+/*
+ * We currently support two types of shared-invalidation messages: one that
+ * invalidates an entry in a catcache, and one that invalidates a relcache
+ * 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.  Other negative values
+ * are available to identify other inval message types.
+ *
+ * Shared-inval events are initially driven by detecting tuple inserts,
+ * updates and deletions in system catalogs (see RelationInvalidateHeapTuple
+ * and RelationMark4RollbackHeapTuple).  Note that some system catalogs have
+ * multiple caches on them (with different indexes).  On detecting a tuple
+ * invalidation in such a catalog, a separate catcache inval message must be
+ * generated for each of its caches.  The catcache inval message carries the
+ * hash index for the target tuple, so that the catcache only needs to search
+ * one hash chain not all its chains.  Of course this assumes that all the
+ * backends are using identical hashing code, but that should be OK.
+ */
+
+typedef struct
+{
+	int16		id;				/* cache ID --- must be first */
+	uint16		hashIndex;		/* hashchain index within this catcache */
+	Oid			dbId;			/* database ID, or 0 if a shared relation */
+	ItemPointerData tuplePtr;	/* tuple identifier in cached relation */
+} SharedInvalCatcacheMsg;
+
+#define SHAREDINVALRELCACHE_ID  (-1)
+
+typedef struct
+{
+	int16		id;				/* type field --- must be first */
+	Oid			dbId;			/* database ID, or 0 if a shared relation */
+	Oid			relId;			/* relation ID */
+} SharedInvalRelcacheMsg;
+
+typedef union
+{
+	int16		id;				/* type field --- must be first */
+	SharedInvalCatcacheMsg cc;
+	SharedInvalRelcacheMsg rc;
+} SharedInvalidationMessage;
+
+
 extern SPINLOCK SInvalLock;
 
 extern int	SInvalShmemSize(int maxBackends);
 extern void CreateSharedInvalidationState(int maxBackends);
 extern void InitBackendSharedInvalidationState(void);
-extern void RegisterSharedInvalid(int cacheId, Index hashIndex,
-					  ItemPointer pointer);
-extern void InvalidateSharedInvalid(void (*invalFunction) (),
-												void (*resetFunction) ());
+extern void SendSharedInvalidMessage(SharedInvalidationMessage *msg);
+extern void ReceiveSharedInvalidMessages(
+	void (*invalFunction) (SharedInvalidationMessage *msg),
+	void (*resetFunction) (void));
 
 extern bool DatabaseHasActiveBackends(Oid databaseId, bool ignoreMyself);
 extern bool TransactionIdIsInProgress(TransactionId xid);