Michael Paquier <michael.paqu...@gmail.com> writes: > On Thu, Oct 20, 2016 at 9:30 PM, Constantin S. Pan <kva...@gmail.com> wrote: >> I tried to fix the problem with a new backend not being >> able to reuse a temporary namespace when it contains >> thousands of temporary tables. I disabled locking of objects >> during namespace clearing process. See the patch attached. >> Please tell me if there are any reasons why this is wrong.
> That's invasive. Invasive or otherwise, it's *completely unacceptable*. Without a lock you have no way to be sure that nothing else is touching the table. A less broken approach might be to split the cleanup into multiple shorter transactions, that is, after every N objects stop and commit what you've done so far. This shouldn't be that hard to do during backend exit, as I'm pretty sure we're starting a new transaction just for this purpose anyway. I don't know if it'd be possible to do it during the automatic cleanup when glomming onto a pre-existing temp namespace, because we're already within a user-started transaction at that point. But if we solve the problem where it's being created, maybe that's enough for now. >> I also added a GUC variable and changed the condition in >> autovacuum to let it nuke orphan tables on its way. >> See another patch attached. > It seems to me that you'd even want to make the drop of orphaned > tables mandatory once it is detected even it is not a wraparound > autovacuum. If we are willing to do that then we don't really have to solve the problem on the backend side. One could expect that autovacuum would clean things up within a few minutes after a backend failure. We'd have to be really darn sure that that "orphaned backend" test can never have any false positives, though. I'm not sure that it was ever designed to be race-condition-proof. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers