Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK |
Дата | |
Msg-id | 0c7975e8-d057-e33c-2a4f-8242144b748b@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: