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, 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_9rdbgjpww3d3jbz6twakzowazigo4...@mail.gmail.com for a very related point about adding subscriptions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
