Re: Truncate in synchronous logical replication failed

On Mon, 26 Apr 2021 at 12:49, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Apr 23, 2021 at 7:18 PM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
>>
>
> The latest patch looks good to me. I have made a minor modification
> and added a commit message in the attached. I would like to once again
> ask whether anybody else thinks we should backpatch this? Just a
> summary for anybody not following this thread:
>
> This patch fixes the Logical Replication of Truncate in synchronous
> commit mode. The Truncate operation acquires an exclusive lock on the
> target relation and indexes and 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 are planning 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.

+1 for apply only on HEAD.

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.