1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
/*-------------------------------------------------------------------------
*
* sinval.h
* POSTGRES shared cache invalidation communication definitions.
*
*
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* src/include/storage/sinval.h
*
*-------------------------------------------------------------------------
*/
/*
* 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 all relcache entries
* * invalidate an smgr cache entry for a specific physical relation
* * invalidate the mapped-relation mapping for a given database
* * invalidate any saved snapshot that might be used to scan a given relation
* More types could be added if needed. The message type is identified by
* the first "int8" 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).
* An update can generate two inval events, one for the old tuple and one for
* the new, but this is reduced to one event if the tuple's hash key doesn't
* change. Note that the inval events themselves don't actually say whether
* the tuple is being inserted or deleted. Also, since we transmit only a
* hash key, there is a small risk of unnecessary invalidations due to chance
* matches of hash keys.
*
* Note that some system catalogs have multiple caches on them (with different
* indexes). On detecting a tuple invalidation in such a catalog, separate
* catcache inval messages must be generated for each of its caches, since
* the hash keys will generally be different.
*
* Catcache, relcache, and snapshot 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
SharedInvalCatcacheMsg;
typedef struct
SharedInvalCatalogMsg;
typedef struct
SharedInvalRelcacheMsg;
typedef struct
SharedInvalSmgrMsg;
typedef struct
SharedInvalRelmapMsg;
typedef struct
SharedInvalSnapshotMsg;
typedef union
SharedInvalidationMessage;
/* Counter of messages processed; don't worry about overflow. */
extern PGDLLIMPORT uint64 SharedInvalidMessageCounter;
extern PGDLLIMPORT volatile sig_atomic_t catchupInterruptPending;
extern void ;
extern void ;
/* signal handler for catchup events (PROCSIG_CATCHUP_INTERRUPT) */
extern void ;
/*
* enable/disable processing of catchup events directly from signal handler.
* The enable routine first performs processing of any catchup events that
* have occurred since the last disable.
*/
extern void ;
extern int ;
extern void ;
extern void ;
/* SINVAL_H */