Re: Fun fact about autovacuum and orphan temp tables
От | Michael Paquier |
---|---|
Тема | Re: Fun fact about autovacuum and orphan temp tables |
Дата | |
Msg-id | CAB7nPqR6SAaPA7yOW3xnp06-893f4QPRwciz6gh8JLeF8NH0oQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fun fact about autovacuum and orphan temp tables (Michael Paquier <michael.paquier@gmail.com>) |
Список | 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 по дате отправления: