Re: "ERROR: deadlock detected" when replicating TRUNCATE
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-17T09:34:40Z
Lists: pgsql-hackers
On Mon, May 17, 2021 at 12:30 PM Peter Smith <smithpb2250@gmail.com> wrote: > The essence of the trouble seems to be that the apply_handle_truncate > function never anticipated it may end up truncating the same table > from 2 separate workers (subscriptions) like this test case is doing. > Probably this is quite an old problem because the > apply_handle_truncate code has not changed much for a long time. The > code of apply_handle_truncate function (worker.c) has a very similar > pattern to the ExecuteTruncate function (tablecmds.c) but the > ExecuteTruncate is using a more powerful AcccessExclusiveLock than the > apply_handle_truncate was using. Right, that's a problem. > > PSA a patch to make the apply_handle_truncate use AccessExclusiveLock > same as the ExecuteTruncate function does. I think the fix makes sense to me. > PSA a patch adding a test for this scenario. I am not sure this test case is exactly targeting the problematic behavior because that will depends upon the order of execution of the apply workers right? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Fix deadlock for multiple replicating truncates of the same table.
- 71787b23e3dc 11.13 landed
- 18c6242b7c6d 12.8 landed
- c83c0257e4c3 13.4 landed
- 6d0eb3855715 14.0 landed
-
Logical replication support for TRUNCATE
- 039eb6e92f20 11.0 cited