RE: Temporary tables prevent autovacuum, leading to XID wraparound - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Temporary tables prevent autovacuum, leading to XID wraparound
Date
Msg-id 0A3221C70F24FB45833433255569204D1FA538FD@G01JPEXMBYT05
Whole thread Raw
In response to Re: Temporary tables prevent autovacuum, leading to XID wraparound  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Temporary tables prevent autovacuum, leading to XID wraparound  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
From: Michael Paquier [mailto:michael@paquier.xyz]
> +   /* Does the backend own the temp schema? */
> +   if (proc->tempNamespaceId != namespaceID)
> +       return false;
> I have a very hard time believing that this is safe lock-less, and a spin
> lock would be enough it seems.

The lwlock in BackendIdGetProc() flushes the CPU cache so that proc->tempNamespaceId reflects the latest value.  Or, do
youmean another spinlock elsewhere?
 


> +   /* Is the backend connected to this database? */
> +   if (proc->databaseId != MyDatabaseId)
> +       return false;
> Wouldn't it be more interesting to do this cleanup as well if the backend
> is *not* connected to the database autovacuum'ed?  This would make the
> cleanup more aggresive, which is better.

IIUC, the above code does what you suggest.  proc->databaseId is the database the client is connected to, and
MyDatabaseIdis the database being autovacuumed (by this autovacuum worker.)
 


Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Next
From: Haribabu Kommi
Date:
Subject: Re: [bug fix] Produce a crash dump before main() on Windows