Re: DROP SUBSCRIPTION and ROLLBACK

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