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 CAB7nPqR6SAaPA7yOW3xnp06-893f4QPRwciz6gh8JLeF8NH0oQ@mail.gmail.com
Whole thread Raw
In response to Re: Fun fact about autovacuum and orphan temp tables  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Fri, Oct 21, 2016 at 2:29 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> 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)

You should as well add your patch to the next commit fest, so as to be
sure that it will attract more reviews and more attention:
https://commitfest.postgresql.org/11/
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fun fact about autovacuum and orphan temp tables
Next
From: Ashutosh Bapat
Date:
Subject: Re: Transactions involving multiple postgres foreign servers