1 /*-------------------------------------------------------------------------
4 * POSTGRES shared cache invalidation communication definitions.
7 * Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
8 * Portions Copyright (c) 1994, Regents of the University of California
10 * $Id: sinval.h,v 1.29 2002/08/29 21:02:12 momjian Exp $
12 *-------------------------------------------------------------------------
17 #include "storage/backendid.h"
18 #include "storage/itemptr.h"
22 * We currently support two types of shared-invalidation messages: one that
23 * invalidates an entry in a catcache, and one that invalidates a relcache
24 * entry. More types could be added if needed. The message type is
25 * identified by the first "int16" field of the message struct. Zero or
26 * positive means a catcache inval message (and also serves as the catcache
27 * ID field). -1 means a relcache inval message. Other negative values
28 * are available to identify other inval message types.
30 * Shared-inval events are initially driven by detecting tuple inserts,
31 * updates and deletions in system catalogs (see CacheInvalidateHeapTuple).
32 * An update generates two inval events, one for the old tuple and one for
33 * the new --- this is needed to get rid of both positive entries for the
34 * old tuple, and negative cache entries associated with the new tuple's
35 * cache key. (This could perhaps be optimized down to one event when the
36 * cache key is not changing, but for now we don't bother to try.) Note that
37 * the inval events themselves don't actually say whether the tuple is being
38 * inserted or deleted.
40 * Note that some system catalogs have multiple caches on them (with different
41 * indexes). On detecting a tuple invalidation in such a catalog, separate
42 * catcache inval messages must be generated for each of its caches. The
43 * catcache inval messages carry the hash value for the target tuple, so
44 * that the catcache only needs to search one hash chain not all its chains,
45 * and so that negative cache entries can be recognized with good accuracy.
46 * (Of course this assumes that all the backends are using identical hashing
47 * code, but that should be OK.)
52 /* note: field layout chosen with an eye to alignment concerns */
53 int16 id; /* cache ID --- must be first */
54 ItemPointerData tuplePtr; /* tuple identifier in cached relation */
55 Oid dbId; /* database ID, or 0 if a shared relation */
56 uint32 hashValue; /* hash value of key for this catcache */
57 } SharedInvalCatcacheMsg;
59 #define SHAREDINVALRELCACHE_ID (-1)
63 int16 id; /* type field --- must be first */
64 Oid dbId; /* database ID, or 0 if a shared relation */
65 Oid relId; /* relation ID */
66 } SharedInvalRelcacheMsg;
70 int16 id; /* type field --- must be first */
71 SharedInvalCatcacheMsg cc;
72 SharedInvalRelcacheMsg rc;
73 } SharedInvalidationMessage;
76 extern int SInvalShmemSize(int maxBackends);
77 extern void CreateSharedInvalidationState(int maxBackends);
78 extern void InitBackendSharedInvalidationState(void);
79 extern void SendSharedInvalidMessage(SharedInvalidationMessage *msg);
80 extern void ReceiveSharedInvalidMessages(
81 void (*invalFunction) (SharedInvalidationMessage *msg),
82 void (*resetFunction) (void));
84 extern bool DatabaseHasActiveBackends(Oid databaseId, bool ignoreMyself);
85 extern bool TransactionIdIsInProgress(TransactionId xid);
86 extern TransactionId GetOldestXmin(bool allDbs);
87 extern int CountActiveBackends(void);
89 /* Use "struct PGPROC", not PGPROC, to avoid including proc.h here */
90 extern struct PGPROC *BackendIdGetProc(BackendId procId);
92 extern int CountEmptyBackendSlots(void);