Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)
Date
Msg-id CA+TgmoZDyS_rfgcJC572djeaevAAdfy92EjM9k8SWGcn7DvzVQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, May 2, 2017 at 5:15 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> On Tue, May 2, 2017 at 12:25 PM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>> > 2) don't drop because we know it won't work.  I see two options:
>> >    c) ignore a drop slot failure, i.e. don't cause a transaction abort.
>> >       An easy way to implement this is just add a PG_TRY block, but we
>> >       dislike adding those and not re-throwing the error.
>>
>> Dislike doesn't seem like the right word.  Unless you rollback a
>> (sub)transaction, none of the cleanup that would normally do is done,
>
> True.  So one possible implementation is that we open a subtransaction
> before dropping the slot, and we abort it if things go south.  This is a
> bit slower, but not critically so.

I think that could work.  Subtransaction abort isn't as fast as I
would sometimes like, but for a DDL command the overhead is pretty
insignificant.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [GENERAL] Column rename in an extension update script
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table