On Mon, Apr 26, 2021 at 12:37 PM Japin Li <japi...@hotmail.com> wrote: > > On Mon, 26 Apr 2021 at 12:49, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Apr 23, 2021 at 7:18 PM osumi.takami...@fujitsu.com > > <osumi.takami...@fujitsu.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. >
Seeing no other suggestions, I have pushed this in HEAD only. Thanks! -- With Regards, Amit Kapila.
