On Thu, Nov 17, 2016 at 4:25 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Nov 17, 2016 at 11:16 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Nov 17, 2016 at 1:41 PM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >>> Okay, let's remove the documentation then. What do you think about the >>> updated version attached? >>> (Even this patch enters into "Needs Review" state). >> >> LGTM. I'll commit it if there are not objections. > > Thank you.
On further reflection, I'm not sure this fixes the original complaint. In fact, it might even make it worse. The performDeletion() call here is going to run inside of a loop that's scanning through pg_class, so all in a single transaction. So we'll actually try to drop ALL orphaned tables for ALL backends that failed to clean up in a single transaction, as opposed to the current state of affairs where we will drop all orphaned tables for ONE backend in a single transaction. If anything, that could require MORE locks. And if it starts failing, then all autovacuum activity in that database will cease. Oops. So now I think that we probably need to make this logic a bit smarter. Add all of the OIDs that need to be dropped to a list. Then have a loop prior to the main loop (where it says "Perform operations on collected tables.") which iterates over that list and drops those tables one by one, starting a transaction every (say) 100 tables or after an error. For bonus points, if a transaction fails, put all of the OIDs except the one that provoked the failure back into the list of OIDs to be dropped, so that we still make a progress even if some DROPs are failing for some reason. That might sound adding unnecessary work just for the sake of paranoia, but I don't think it is. Failures here won't be common, but since they are entirely automated there will be no human intelligence available to straighten things out. Barring considerable caution, we'll just enter a flaming death spiral. -- 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
