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
-
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