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:

Reply via email to