From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | peter(dot)eisentraut(at)2ndquadrant(dot)com |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Get stuck when dropping a subscription during synchronizing table |
Date: | 2017-05-18 15:11:37 |
Message-ID: | 20170518151137.GT843225@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 15, 2017 at 03:28:14AM +0000, Noah Misch wrote:
> On Mon, May 08, 2017 at 06:27:30PM +0900, Masahiko Sawada wrote:
> > I encountered a situation where DROP SUBSCRIPTION got stuck when
> > initial table sync is in progress. In my environment, I created
> > several tables with some data on publisher. I created subscription on
> > subscriber and drop subscription immediately after that. It doesn't
> > always happen but I often encountered it on my environment.
> >
> > ps -x command shows the following.
> >
> > 96796 ? Ss 0:00 postgres: masahiko postgres [local] DROP
> > SUBSCRIPTION
> > 96801 ? Ts 0:00 postgres: bgworker: logical replication
> > worker for subscription 40993 waiting
> > 96805 ? Ss 0:07 postgres: bgworker: logical replication
> > worker for subscription 40993 sync 16418
> > 96806 ? Ss 0:01 postgres: wal sender process masahiko [local] idle
> > 96807 ? Ss 0:00 postgres: bgworker: logical replication
> > worker for subscription 40993 sync 16421
> > 96808 ? Ss 0:00 postgres: wal sender process masahiko [local] idle
> >
> > The DROP SUBSCRIPTION process (pid 96796) is waiting for the apply
> > worker process (pid 96801) to stop while holding a lock on
> > pg_subscription_rel. On the other hand the apply worker is waiting for
> > acquiring a tuple lock on pg_subscription_rel needed for heap_update.
> > Also table sync workers (pid 96805 and 96807) are waiting for the
> > apply worker process to change their status.
> >
> > Also, even when DROP SUBSCRIPTION is done successfully, the table sync
> > worker can be orphaned because I guess that the apply worker can exit
> > before change status of table sync worker.
> >
> > I'm using 1f30295.
>
> [Action required within three days. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 10 open item. Peter,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> v10 open item, please let us know. Otherwise, please observe the policy on
> open item ownership[1] and send a status update within three calendar days of
> this message. Include a date for your subsequent status update. Testers may
> discover new open items at any time, and I want to plan to get them all fixed
> well in advance of shipping v10. Consequently, I will appreciate your efforts
> toward speedy resolution. Thanks.
>
> [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is past due for
your status update. Please reacquaint yourself with the policy on open item
ownership[1] and then reply immediately. If I do not hear from you by
2017-05-19 16:00 UTC, I will transfer this item to release management team
ownership without further notice.
[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-05-18 15:38:53 | Re: [Proposal] Allow users to specify multiple tables in VACUUM commands |
Previous Message | Tom Lane | 2017-05-18 15:03:52 | Re: [Proposal] Allow users to specify multiple tables in VACUUM commands |