Re: Get stuck when dropping a subscription during synchronizing table
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>,
tushar <tushar.ahuja@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>,
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-06-20T02:54:41Z
Lists: pgsql-hackers
On Tue, Jun 20, 2017 at 10:55 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 6/1/17 13:37, Petr Jelinek wrote: >> On 01/06/17 17:32, Masahiko Sawada wrote: >>> On Thu, May 25, 2017 at 5:29 PM, tushar <tushar.ahuja@enterprisedb.com> wrote: >>>> After applying all your patches, drop subscription no more hangs while >>>> dropping subscription but there is an error "ERROR: tuple concurrently >>>> updated" in the log file of >>>> standby. >>> >>> I tried to reproduce this issue with latest four patches I submit but >>> it didn't happen. I guess this issue doesn't related to the issues >>> reported on this thread and another factor might be cause of this >>> issue. It would be good to test the same again with latest four >>> patches or after solved current some open items. >> >> That's because your additional patch kills the workers that do the >> concurrent update. While that's probably okay, I still plan to look into >> making the subscription and state locking more robust. > > It seems we have gotten off track here a bit. What is the current > proposal to fix "tuple concurrently updated" during DROP SUBSCRiPTION? I think there is no proposal for it so far. The current proposal is to fix this problem during ALTER SUBSCRIPTION. > It seems to me we could just take a stronger lock around > RemoveSubscriptionRel(), so that workers can't write in there concurrently. > Since we reduced the lock level of updating pg_subscription_rel by commit 521fd4795e3e the same deadlock issue will appear if we just take a stronger lock level. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Commits
-
Fix violations of CatalogTupleInsert/Update/Delete abstraction.
- a571c7f661a7 10.0 cited
-
Use standard interrupt handling in logical replication launcher.
- 2c48f5db64b1 10.0 landed
-
Make tablesync worker exit when apply dies while it was waiting for it
- 3c9bc2157a4f 10.0 cited
-
Use weaker locks when updating pg_subscription_rel
- 521fd4795e3e 10.0 cited