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,
so you might leak buffer pins, memory, or other resources. Unless the
code that can be run in the TRY/CATCH block is sufficiently restricted
as to make that a non-issue, which is rarely the case, it's not going
to work reliably at all. I wonder why this API was even designed in a
way that made not re-throwing the error an option.
(I've wondered whether we should have some kind of mini-transaction
that is cheaper to abort but does only a critical subset of the
cleanup, but I haven't been able to figure out how you'd know whether
you only need to blow up the mini-transaction or whether you need to
kill the enclosing real (sub)transaction.)
> d) rethink drop slot completely; maybe instead of doing it
> immediately, it should be a separate task, so we first close the
> current transaction (which dropped the subscription) and then we open
> a second one to drop the slot, so that if the drop slot fails, the
> subscription does not come back to life.
Something like this might work, although it's not clear how it
interacts with DROP .. CASCADE. See
http://postgr.es/m/CA+Tgmob_hy0uQS9vq_9rDBgjpww3D3jBZ6twAKZOwaZigo4C3g@mail.gmail.com
for a very related point about adding subscriptions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
