1
/*-------------------------------------------------------------------------
4
* POSTGRES shared cache invalidation communication definitions.
7
* Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
8
* Portions Copyright (c) 1994, Regents of the University of California
12
*-------------------------------------------------------------------------
17
#include "storage/itemptr.h"
18
#include "storage/relfilenode.h"
22
* We currently support three types of shared-invalidation messages: one that
23
* invalidates an entry in a catcache, one that invalidates a relcache entry,
24
* and one that invalidates an smgr cache entry. More types could be added
25
* if needed. The message type is identified by the first "int16" field of
26
* the message struct. Zero or positive means a catcache inval message (and
27
* also serves as the catcache ID field). -1 means a relcache inval message.
28
* -2 means an smgr inval message. Other negative values are available to
29
* identify other inval message types.
31
* Catcache inval events are initially driven by detecting tuple inserts,
32
* updates and deletions in system catalogs (see CacheInvalidateHeapTuple).
33
* An update generates two inval events, one for the old tuple and one for
34
* the new --- this is needed to get rid of both positive entries for the
35
* old tuple, and negative cache entries associated with the new tuple's
36
* cache key. (This could perhaps be optimized down to one event when the
37
* cache key is not changing, but for now we don't bother to try.) Note that
38
* the inval events themselves don't actually say whether the tuple is being
39
* inserted or deleted.
41
* Note that some system catalogs have multiple caches on them (with different
42
* indexes). On detecting a tuple invalidation in such a catalog, separate
43
* catcache inval messages must be generated for each of its caches. The
44
* catcache inval messages carry the hash value for the target tuple, so
45
* that the catcache only needs to search one hash chain not all its chains,
46
* and so that negative cache entries can be recognized with good accuracy.
47
* (Of course this assumes that all the backends are using identical hashing
48
* code, but that should be OK.)
53
/* note: field layout chosen with an eye to alignment concerns */
54
int16 id; /* cache ID --- must be first */
55
ItemPointerData tuplePtr; /* tuple identifier in cached relation */
56
Oid dbId; /* database ID, or 0 if a shared relation */
57
uint32 hashValue; /* hash value of key for this catcache */
58
} SharedInvalCatcacheMsg;
60
#define SHAREDINVALRELCACHE_ID (-1)
64
int16 id; /* type field --- must be first */
65
Oid dbId; /* database ID, or 0 if a shared relation */
66
Oid relId; /* relation ID */
67
} SharedInvalRelcacheMsg;
69
#define SHAREDINVALSMGR_ID (-2)
73
int16 id; /* type field --- must be first */
74
RelFileNode rnode; /* physical file ID */
79
int16 id; /* type field --- must be first */
80
SharedInvalCatcacheMsg cc;
81
SharedInvalRelcacheMsg rc;
82
SharedInvalSmgrMsg sm;
83
} SharedInvalidationMessage;
86
extern void SendSharedInvalidMessages(const SharedInvalidationMessage *msgs,
88
extern void ReceiveSharedInvalidMessages(
89
void (*invalFunction) (SharedInvalidationMessage *msg),
90
void (*resetFunction) (void));
92
/* signal handler for catchup events (SIGUSR1) */
93
extern void CatchupInterruptHandler(SIGNAL_ARGS);
96
* enable/disable processing of catchup events directly from signal handler.
97
* The enable routine first performs processing of any catchup events that
98
* have occurred since the last disable.
100
extern void EnableCatchupInterrupt(void);
101
extern bool DisableCatchupInterrupt(void);
103
#endif /* SINVAL_H */