Fix Logical Replication of Truncate in synchronous commit mode.
authorAmit Kapila <akapila@postgresql.org>
Tue, 27 Apr 2021 02:58:26 +0000 (08:28 +0530)
committerAmit Kapila <akapila@postgresql.org>
Tue, 27 Apr 2021 02:58:26 +0000 (08:28 +0530)
commite7eea52b2d61917fbbdac7f3f895e4ef636e935b
tree2cfd67726c0e6b0e2535cb132a4cee271826c49e
parent6dd1042eda0acdabaab352c19b783288de62b587
Fix Logical Replication of Truncate in synchronous commit mode.

The Truncate operation acquires an exclusive lock on the target relation
and indexes. It then waits for logical replication of the operation to
finish at commit. Now because we are acquiring the shared lock on the
target index to get index attributes in pgoutput while sending the
changes for the Truncate operation, it leads to a deadlock.

Actually, we don't need to acquire a lock on the target index as we build
the cache entry using a historic snapshot and all the later changes are
absorbed while decoding WAL. So, we wrote a special purpose function for
logical replication to get a bitmap of replica identity attribute numbers
where we get that information without locking the target index.

We decided not to backpatch this as there doesn't seem to be any field
complaint about this issue since it was introduced in commit 5dfd1e5a in
v11.

Reported-by: Haiying Tang
Author: Takamichi Osumi, test case by Li Japin
Reviewed-by: Amit Kapila, Ajin Cherian
Discussion: https://postgr.es/m/OS0PR01MB6113C2499C7DC70EE55ADB82FB759@OS0PR01MB6113.jpnprd01.prod.outlook.com
src/backend/replication/logical/proto.c
src/backend/utils/cache/relcache.c
src/include/utils/relcache.h
src/test/subscription/t/010_truncate.pl