RE: removal of dangling temp tables - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: removal of dangling temp tables
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB5DC66@G01JPEXMBYT05
Whole thread Raw
In response to Re: removal of dangling temp tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: removal of dangling temp tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com]
> The more aggressive action is to backpatch 943576bddcb5 ("Make autovacuum
> more aggressive to remove orphaned temp tables") which is currently only
> in pg11.  We would put the new PGPROC member at the end of the struct, to
> avoid ABI incompatibilities, but it'd bring trouble for extensions that
> put PGPROC in arrays.  I checked the code of some known extensions; found
> that pglogical uses PGPROC, but only pointers to it, so it wouldn't be
> damaged by the proposed change AFAICS.

+1
I think this is a bug from a user's perspective that garbage is left.  I want to believe that fixing bugs of PostgreSQL
itselfare prioritized over the ABI compatibility for extensions, if we have to choose one of them.
 



> Another possibly useful change is to make DISCARD ALL and DISCARD TEMP delete
> everything in what would be the backend's temp namespace, even if it hasn't
> been initialized yet.  This would cover the case where a connection pooler
> keeps the connection open for a very long time, which I think is a common
> case.

That sounds good.


Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Fix failure to check for open() or fsync() failures.
Next
From: Alvaro Herrera
Date:
Subject: Re: removal of dangling temp tables