Re: Fun fact about autovacuum and orphan temp tables

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: "Constantin S(dot) Pan" <kvapen(at)gmail(dot)com>
Cc: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fun fact about autovacuum and orphan temp tables
Date: 2016-10-21 05:29:24
Message-ID: CAB7nPqTmeDmf4+LjQMBAKDWfPXO28cF7aL-5JGWKegyNQG_LLA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 20, 2016 at 9:30 PM, Constantin S. Pan <kvapen(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-10-21 05:31:11 Re: Fun fact about autovacuum and orphan temp tables
Previous Message Michael Paquier 2016-10-21 05:16:36 Re: Fun fact about autovacuum and orphan temp tables