On Wed, Feb 8, 2017 at 9:01 AM, Michael Paquier <[email protected]> wrote: > On Wed, Feb 8, 2017 at 1:30 AM, Fujii Masao <[email protected]> wrote: >> On Wed, Feb 8, 2017 at 12:26 AM, Petr Jelinek >> <[email protected]> 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
drop_subscription_and_rollback_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
