Re: [HACKERS] DROP SUBSCRIPTION hangs if sub is disabled in the same transaction - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] DROP SUBSCRIPTION hangs if sub is disabled in the same transaction
Date
Msg-id CAD21AoCUiYJU_auS=1GqqFbr5Q2GwQc4dBLJa_gS-+ex_RYYJQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] DROP SUBSCRIPTION hangs if sub is disabled in the same transaction  (Arseny Sher <a.sher@postgrespro.ru>)
List pgsql-hackers
On Wed, Sep 13, 2017 at 12:48 AM, Arseny Sher <a.sher@postgrespro.ru> wrote:
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>
>> FWIW, perhaps we can change the replication origin management so that
>> DROP SUBSCRIPTION doesn't drop the replication origin and the apply
>> worker itself removes it when exit. When an apply worker exits it
>> removes the replication origin if the corresponding subscription had
>> been removed.
>

After thought, I think we can change it like followings.
* If the replication origin is not acquired, DROP SUBSCRIPTION can drop it.
* If the replication origin is acquired by someone DROP SUBSCRIPTION
takes over a job of dropping it to the apply worker.
* The apply worker drops the replication origin when exit if the apply
worker has to drop it.

> I don't think this is reliable -- what if worker suddenly dies without
> accomplishing the job?

The apply worker will be launched by the launcher later. If DROP
SUBSCRIPTION is issued before the apply worker launches again, DROP
SUBSCRIPTION itself can remove the replication origin.

Attached a very rough patch for reference. It's very ugly but we can
deal with this case.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Setting pd_lower in GIN metapage
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions