database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-25 13:17:41 +03:00
Code Activity

Avoid invalidating all RelationSyncCache entries on publication rename.

Browse Source 
On Publication rename, we need to only invalidate the RelationSyncCache
entries corresponding to relations that are part of the publication being
renamed.

As part of this patch, we introduce a new invalidation message to
invalidate the cache maintained by the logical decoding output plugin. We
can't use existing relcache invalidation for this purpose, as that would
unnecessarily cause relcache invalidations in other backends.

This will improve performance by building fewer relation cache entries
during logical replication.

Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Author: Shlok Kyal <shlok.kyal.oss@gmail.com>
Reviewed-by: Hou Zhijie <houzj.fnst@fujitsu.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://postgr.es/m/OSCPR01MB14966C09AA201EFFA706576A7F5C92@OSCPR01MB14966.jpnprd01.prod.outlook.com
This commit is contained in:
Amit Kapila
2025-03-13 09:03:45 +05:30
parent 75da2bece6
commit 3abe9dc188
10 changed files with 302 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/include/storage/sinval.h
View File

@@ -27,6 +27,7 @@
* * 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
* * invalidate a RelationSyncCache entry for a specific 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).
@@ -46,12 +47,12 @@
* 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.
* Catcache, relcache, relsynccache, 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.
@@ -110,6 +111,16 @@ typedef struct
Oid relId; /* relation ID */
} SharedInvalSnapshotMsg;
#define SHAREDINVALRELSYNC_ID (-6)
typedef struct
{
int8 id; /* type field --- must be first */
Oid dbId; /* database ID */
Oid relid; /* relation ID, or 0 if whole
* RelationSyncCache */
} SharedInvalRelSyncMsg;
typedef union
{
int8 id; /* type field --- must be first */
@@ -119,6 +130,7 @@ typedef union
SharedInvalSmgrMsg sm;
SharedInvalRelmapMsg rm;
SharedInvalSnapshotMsg sn;
SharedInvalRelSyncMsg rs;
} SharedInvalidationMessage;