Horton

Re: Temporary tables prevent autovacuum, leading to XID wraparound

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-08-13T17:03:59Z
Lists: pgsql-hackers

Attachments

On Mon, Aug 13, 2018 at 02:56:16AM -0700, Andres Freund wrote:
> On 2018-08-09 18:50:47 +0200, Michael Paquier wrote:
> I don't think that comment, nor the comment that you ended up
> committing:
> +
> +           /*
> +            * Reset the temporary namespace flag in MyProc.  We assume that
> +            * this operation is atomic.  Even if it is not, the temporary
> +            * table which created this namespace is still locked until this
> +            * transaction aborts so it would not be visible yet, acting as a
> +            * barrier.
> +            */
> 
> is actually correct. *Holding* a lock isn't a memory barrier. Acquring
> or releasing one is.

I cannot guess what you think, but would something like the attached be
more adapted?  Both things look rather similar to me now, likely for you
it does not.
--
Michael

Commits

  1. Clarify comment about assignment and reset of temp namespace ID in MyProc

  2. Make autovacuum more aggressive to remove orphaned temp tables

  3. Don't count background workers against a user's connection limit.