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

  1. Fix violations of CatalogTupleInsert/Update/Delete abstraction.

  2. Use standard interrupt handling in logical replication launcher.

  3. Make tablesync worker exit when apply dies while it was waiting for it

  4. Use weaker locks when updating pg_subscription_rel