On Tue, May 2, 2017 at 5:15 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> On Tue, May 2, 2017 at 12:25 PM, Alvaro Herrera
>> <alvhe...@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
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: