Replica Identity check of partition table on subscriber
Yu Shi (Fujitsu) <shiy.fnst@fujitsu.com>
From: "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Date: 2022-06-08T08:46:46Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-partition-map-cache-issues.patch (application/octet-stream) patch v1-0001
- v1-0002-Check-partition-table-replica-identity-on-subscri.patch (application/octet-stream) patch v1-0002
- backtrace.txt (text/plain)
Hi hackers,
I saw a problem in logical replication, when the target table on subscriber is a
partitioned table, it only checks whether the Replica Identity of partitioned
table is consistent with the publisher, and doesn't check Replica Identity of
the partition.
For example:
-- publisher --
create table tbl (a int not null, b int);
create unique INDEX ON tbl (a);
alter table tbl replica identity using INDEX tbl_a_idx;
create publication pub for table tbl;
-- subscriber --
-- table tbl (parent table) has RI index, while table child has no RI index.
create table tbl (a int not null, b int) partition by range (a);
create table child partition of tbl default;
create unique INDEX ON tbl (a);
alter table tbl replica identity using INDEX tbl_a_idx;
create subscription sub connection 'port=5432 dbname=postgres' publication pub;
-- publisher --
insert into tbl values (11,11);
update tbl set a=a+1;
It caused an assertion failure on subscriber:
TRAP: FailedAssertion("OidIsValid(idxoid) || (remoterel->replident == REPLICA_IDENTITY_FULL)", File: "worker.c", Line: 2088, PID: 1616523)
The backtrace is attached.
We got the assertion failure because idxoid is invalid, as table child has no
Replica Identity or Primary Key. We have a check in check_relation_updatable(),
but what it checked is table tbl (the parent table) and it passed the check.
I think one approach to fix it is to check the target partition in this case,
instead of the partitioned table.
When trying to fix it, I saw some other problems about updating partition map
cache.
a) In logicalrep_partmap_invalidate_cb(), the type of the entry in
LogicalRepPartMap should be LogicalRepPartMapEntry, instead of
LogicalRepRelMapEntry.
b) In logicalrep_partition_open(), it didn't check if the entry is valid.
c) When the publisher send new relation mapping, only relation map cache will be
updated, and partition map cache wouldn't. I think it also should be updated
because it has remote relation information, too.
Attach two patches which tried to fix them.
0001 patch: fix the above three problems about partition map cache.
0002 patch: fix the assertion failure, check the Replica Identity of the
partition if the target table is a partitioned table.
Thanks to Hou Zhijie for helping me in the first patch.
I will add a test for it later if no one doesn't like this fix.
Regards,
Shi yu
Commits
-
Fix memory leak due to LogicalRepRelMapEntry.attrmap.
- ac0e2d387a04 15.0 landed
- 3238b5c330bc 14.5 landed
- 3a6ef0cdf311 13.8 landed
- 9e0d9a24ef88 12.12 landed
- ed2a7a6bf67d 11.17 landed
- d873b5a5a340 10.22 landed
-
Fix stale values in partition map entries on subscribers.
- 75bfe7434d41 15.0 landed
- f0022a77d011 14.5 landed
- 419c72715172 13.8 landed
-
Fix partition table's REPLICA IDENTITY checking on the subscriber.
- 26b3455afaa9 15.0 landed
- 5f113d60e998 13.8 landed
- 52d5ea9adb01 14.5 landed
-
Fix data inconsistency between publisher and subscriber.
- b7658c24c7c1 15.0 landed
- 0980adfd4d02 14.5 landed
- 1f9a7738eb84 13.8 landed
-
Fix cache look-up failures while applying changes in logical replication.
- 16f5a8da76f2 13.8 landed
- d457cb4e8a5e 14.5 landed
- 5a97b1325453 15.0 landed
-
Add logical replication support to replicate into partitioned tables
- f1ac27bfda6c 13.0 cited