Re: Fun fact about autovacuum and orphan temp tables - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fun fact about autovacuum and orphan temp tables
Date
Msg-id CAB7nPqTmeDmf4+LjQMBAKDWfPXO28cF7aL-5JGWKegyNQG_LLA@mail.gmail.com
Whole thread Raw
In response to Re: Fun fact about autovacuum and orphan temp tables  ("Constantin S. Pan" <kvapen@gmail.com>)
Responses Re: Fun fact about autovacuum and orphan temp tables  (Michael Paquier <michael.paquier@gmail.com>)
Re: Fun fact about autovacuum and orphan temp tables  ("Constantin S. Pan" <kvapen@gmail.com>)
Re: Fun fact about autovacuum and orphan temp tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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. I am wondering if a cleaner approach here would be a
flag in deleteOneObject() that performs the lock cleanup, as that's
what you are trying to solve here.

> 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. Dangling temp tables have higher chances to hit users than
diagnostic of orphaned temp tables after a crash. (A background worker
could be used for existing versions to clean up that more aggressively
actually)
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fun fact about autovacuum and orphan temp tables
Next
From: Michael Paquier
Date:
Subject: Re: Fun fact about autovacuum and orphan temp tables