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
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 |