From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: "ERROR: deadlock detected" when replicating TRUNCATE |
Date: | 2021-05-17 09:34:40 |
Message-ID: | CAFiTN-tbL_HCKXW1fAY06bHET=YZuYve50OcompA7k4Au-KVjg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 17, 2021 at 12:30 PM Peter Smith <smithpb2250(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | tanghy.fnst@fujitsu.com | 2021-05-17 09:36:33 | RE: "ERROR: deadlock detected" when replicating TRUNCATE |
Previous Message | houzj.fnst@fujitsu.com | 2021-05-17 09:18:26 | RE: making update/delete of inheritance trees scale better |