Re: More aggressive vacuuming of temporary tables - Mailing list pgsql-hackers

From Andres Freund
Subject Re: More aggressive vacuuming of temporary tables
Date
Msg-id 20201029011147.b5dbua3m4mdk42op@alap3.anarazel.de
Whole thread Raw
In response to Re: More aggressive vacuuming of temporary tables  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 2020-10-14 13:31:03 -0700, Andres Freund wrote:
> I was thinking about this a bit more, and I think the answer might be to
> use Min(latestCompletedXid, MyProc->xid). That would, as far as I can
> tell, never miss something vacuumable in a temporary table, doesn't
> require to know whether we're running as the top-level command.
> 
> The reason for preferring latestCompletedXid over nextXid is that the
> former is protected by ProcArrayLock and already accessed in
> GetSnapshotData(), so we can cheaply compute the horizons as part of
> pruning.
> 
> I think that cannot miss something vacuumable in a temp table for VACUUM
> because that would have to have been left over by an already completed
> transaction (by us, before the VACUUM).
> 
> In addition this allows HOT pruning etc on temp tables to be just as
> aggressive as VACUUM is.
> 
> I wrote a patch to do so for [1], but it seemed topically more relevant
> here. Running tests in a loop, no failures after the first few
> iterations.
> 
> [1] https://postgr.es/m/20200921212003.wrizvknpkim2whzo%40alap3.anarazel.de

Pushed this change in logic. The only "real" change is that the horizon
for backends without an xid needs to be latestCompletedXid + 1, rather
than just latestCompletedXid. The horizon indicates the oldest
*non*-removable xid, and for temp tables latestCompletedXid can always
be vacuumed when no xid is assigned.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Andres Freund
Date:
Subject: Re: recovering from "found xmin ... from before relfrozenxid ..."