RE: Temporary tables prevent autovacuum, leading to XID wraparound

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

In response to

Responses

Browse pgsql-hackers by date

  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