On Wed, Feb 8, 2017 at 9:01 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Feb 8, 2017 at 1:30 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Feb 8, 2017 at 12:26 AM, Petr Jelinek
>> <petr.jelinek@2ndquadrant.com> wrote:
>>> For example what happens if apply crashes during the DROP
>>> SUBSCRIPTION/COMMIT and is not started because the delete from catalog
>>> is now visible so the subscription is no longer there?
>>
>> Another idea is to treat DROP SUBSCRIPTION in the same way as VACUUM, i.e.,
>> make it emit an error if it's executed within user's transaction block.
>
> It seems to me that this is exactly Petr's point: using
> PreventTransactionChain() to prevent things to happen.
Agreed. It's better to prevent to be executed inside user transaction
block. And I understood there is too many failure scenarios we need to
handle.
>> Also DROP SUBSCRIPTION should call CommitTransactionCommand() just
>> after removing the entry from pg_subscription, then connect to the publisher
>> and remove the replication slot.
>
> For consistency that may be important.
Agreed.
Attached patch, please give me feedback.
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