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