From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Michael Paquier' <michael(at)paquier(dot)xyz> |
Cc: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Temporary tables prevent autovacuum, leading to XID wraparound |
Date: | 2018-07-18 07:34:10 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FA538FD@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Michael Paquier [mailto:michael(at)paquier(dot)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 you mean 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 MyDatabaseId is the database being autovacuumed (by this autovacuum worker.)
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2018-07-18 07:37:37 | Re: [bug fix] Produce a crash dump before main() on Windows |
Previous Message | Konstantin Knizhnik | 2018-07-18 07:32:06 | Re: [HACKERS] PATCH: multivariate histograms and MCV lists |