1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* inval.h
|
1996-08-28 03:59:28 +02:00
|
|
|
* POSTGRES cache invalidation dispatcher definitions.
|
|
|
|
*
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/utils/inval.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef INVAL_H
|
|
|
|
#define INVAL_H
|
|
|
|
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "access/htup.h"
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
#include "storage/relfilelocator.h"
|
2008-06-19 02:46:06 +02:00
|
|
|
#include "utils/relcache.h"
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2021-07-13 21:01:01 +02:00
|
|
|
extern PGDLLIMPORT int debug_discard_caches;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2011-08-17 01:27:46 +02:00
|
|
|
typedef void (*SyscacheCallbackFunction) (Datum arg, int cacheid, uint32 hashvalue);
|
2008-09-09 20:58:09 +02:00
|
|
|
typedef void (*RelcacheCallbackFunction) (Datum arg, Oid relid);
|
2002-04-30 00:14:34 +02:00
|
|
|
|
|
|
|
|
2001-06-19 21:42:16 +02:00
|
|
|
extern void AcceptInvalidationMessages(void);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2004-07-01 02:52:04 +02:00
|
|
|
extern void AtEOXact_Inval(bool isCommit);
|
|
|
|
|
2004-07-28 16:23:31 +02:00
|
|
|
extern void AtEOSubXact_Inval(bool isCommit);
|
2004-07-01 02:52:04 +02:00
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
extern void PostPrepare_Inval(void);
|
|
|
|
|
2004-07-01 02:52:04 +02:00
|
|
|
extern void CommandEndInvalidationMessages(void);
|
2000-01-10 07:30:56 +01:00
|
|
|
|
2011-08-17 01:27:46 +02:00
|
|
|
extern void CacheInvalidateHeapTuple(Relation relation,
|
|
|
|
HeapTuple tuple,
|
|
|
|
HeapTuple newtuple);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
extern void CacheInvalidateCatalog(Oid catalogId);
|
|
|
|
|
2004-02-10 02:55:27 +01:00
|
|
|
extern void CacheInvalidateRelcache(Relation relation);
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
extern void CacheInvalidateRelcacheAll(void);
|
|
|
|
|
2004-02-10 02:55:27 +01:00
|
|
|
extern void CacheInvalidateRelcacheByTuple(HeapTuple classTuple);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2004-05-06 18:10:57 +02:00
|
|
|
extern void CacheInvalidateRelcacheByRelid(Oid relid);
|
|
|
|
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
extern void CacheInvalidateSmgr(RelFileLocatorBackend rlocator);
|
2010-02-03 02:14:17 +01:00
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
extern void CacheInvalidateRelmap(Oid databaseId);
|
|
|
|
|
2002-04-30 00:14:34 +02:00
|
|
|
extern void CacheRegisterSyscacheCallback(int cacheid,
|
2008-09-09 20:58:09 +02:00
|
|
|
SyscacheCallbackFunction func,
|
2002-04-30 00:14:34 +02:00
|
|
|
Datum arg);
|
|
|
|
|
2008-09-09 20:58:09 +02:00
|
|
|
extern void CacheRegisterRelcacheCallback(RelcacheCallbackFunction func,
|
2002-04-30 00:14:34 +02:00
|
|
|
Datum arg);
|
|
|
|
|
2011-08-17 01:27:46 +02:00
|
|
|
extern void CallSyscacheCallbacks(int cacheid, uint32 hashvalue);
|
2010-02-07 21:48:13 +01:00
|
|
|
|
Introduce logical decoding.
This feature, building on previous commits, allows the write-ahead log
stream to be decoded into a series of logical changes; that is,
inserts, updates, and deletes and the transactions which contain them.
It is capable of handling decoding even across changes to the schema
of the effected tables. The output format is controlled by a
so-called "output plugin"; an example is included. To make use of
this in a real replication system, the output plugin will need to be
modified to produce output in the format appropriate to that system,
and to perform filtering.
Currently, information can be extracted from the logical decoding
system only via SQL; future commits will add the ability to stream
changes via walsender.
Andres Freund, with review and other contributions from many other
people, including Álvaro Herrera, Abhijit Menon-Sen, Peter Gheogegan,
Kevin Grittner, Robert Haas, Heikki Linnakangas, Fujii Masao, Abhijit
Menon-Sen, Michael Paquier, Simon Riggs, Craig Ringer, and Steve
Singer.
2014-03-03 22:32:18 +01:00
|
|
|
extern void InvalidateSystemCaches(void);
|
2021-10-24 03:36:38 +02:00
|
|
|
extern void InvalidateSystemCachesExtended(bool debug_discard);
|
2020-07-23 04:49:07 +02:00
|
|
|
|
|
|
|
extern void LogLogicalInvalidations(void);
|
1996-08-28 03:59:28 +02:00
|
|
|
#endif /* INVAL_H */
|