Michael Paquier <michael.paquier@gmail.com> writes:
> On Thu, Oct 20, 2016 at 9:30 PM, Constantin S. Pan <kvapen@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