On 07/02/17 16:26, Petr Jelinek wrote: > On 07/02/17 13:10, Masahiko Sawada wrote: >> I think the logical replication should not stop and the corresponding >> replication slot and replication origin should not be removed until >> the transaction commits. >> >> The solution for this I came up with is that the launcher process >> stops the apply worker after DROP SUBSCRIPTION is committed rather >> than DropSubscription does. And the apply worker drops replication >> slot and replication origin before exits. Attached draft patch fixes >> this issue. >> > > I don't think we can allow the slot drop to be postponed. There is too > many failure scenarios where we would leave the remote slot in the > database and that's not acceptable IMHO. > > 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? >
Not to mention that slot creation/drop is not transactional by itself so even if there was some way to tie remote transaction to local transaction (like say 2pc), it would still not work with ROLLBACK. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
