Re: Get stuck when dropping a subscription during synchronizing table

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Noah Misch <noah@leadboat.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-15T01:22:55Z
Lists: pgsql-hackers
On Thu, Jun 15, 2017 at 7:35 AM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:
> On 13/06/17 21:49, Peter Eisentraut wrote:
>> On 6/13/17 02:33, Noah Misch wrote:
>>>> Steps to reproduce -
>>>> X cluster -> create 100 tables , publish all tables  (create publication pub
>>>> for all tables);
>>>> Y Cluster -> create 100 tables ,create subscription(create subscription sub
>>>> connection 'user=centos host=localhost' publication pub;
>>>> Y cluster ->drop subscription - drop subscription sub;
>>>>
>>>> check the log file on Y cluster.
>>>>
>>>> Sometime , i have seen this error on psql prompt and drop subscription
>>>> operation got failed at first attempt.
>>>>
>>>> postgres=# drop subscription sub;
>>>> ERROR:  tuple concurrently updated
>>>> postgres=# drop subscription sub;
>>>> NOTICE:  dropped replication slot "sub" on publisher
>>>> DROP SUBSCRIPTION
>>>
>>> [Action required within three days.  This is a generic notification.]
>>
>> It's being worked on.  Let's see by Thursday.
>>
>
> Attached fixes it (it was mostly about order of calls). I also split the
> SetSubscriptionRelState into 2 separate interface while I was changing
> it, because now that the update_only bool was added it has become quite
> strange to have single interface for what is basically two separate
> functions.
>
> There are still couple of remaining issues from this thread though.
> Namely the AccessExclusiveLock of the pg_subscription catalog which is
> not very pretty, but we need a way to block launcher from accessing the
> subscription which is being dropped and make sure it will not start new
> workers for it afterwards. Question is how however as by the time
> launcher can lock individual subscription it is already processing it.
> So it looks to me like we'd need to reread the catalog with new snapshot
> after the lock was acquired which seems bit wasteful (I wonder if we
> could just AcceptInvalidationMessages and refetch from syscache). Any
> better ideas?
>
> Other related problem is locking of subscriptions during operations on
> them, especially AlterSubscription seems like it should lock the
> subscription itself. I did that in 0002.
>

Thank you for the patch! Sorry I don't have a time for it today but
I'll review these patches tomorrow.

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