RE: Truncate in synchronous logical replication failed

On Monday, April 26, 2021 1:50 PM 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.
Thank you for updating the patch.

I think we need one space for "targetindex" in the commit message.
From my side, there is no more additional comments !

> 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.
Please anyone, share your opinion on this matter, when you have.

Best Regards,
Takamichi Osumi