On Fri, Oct 21, 2016 at 2:29 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Oct 20, 2016 at 9:30 PM, Constantin S. Pan <kva...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
