Re: Fun fact about autovacuum and orphan temp tables

On Fri, Oct 21, 2016 at 2:29 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> 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)

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