Re: More aggressive vacuuming of temporary tables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-09-08T22:13:58Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2020-09-08 15:24:54 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >>> But now I do wonder why we need to know whether the command is top level >>> or not? Why isn't the correct thing to instead look at what the current >>> backend's xmin is? Seems like you could just replace >>> *oldestXmin = XidFromFullTransactionId(ReadNextFullTransactionId()); >>> with >>> *oldestXmin = MyProc->xmin; >>> Assert(TransactionIdIsValid(*oldestXmin)); >> Ummm ... since VACUUM doesn't run inside a transaction, it won't be >> advertising an xmin will it? > We do run it in a transaction though: Ah. But still, this is not the semantics I want for VACUUM, because the process xmin will involve other processes' behavior. The point of the change as far as I'm concerned is to ensure vacuuming of dead temp rows independent of anything else in the system. regards, tom lane
Commits
-
Centralize horizon determination for temp tables, fixing bug due to skew.
- 94bc27b57680 14.0 landed
-
Improve test coverage of ginvacuum.c.
- 4c51a2d1e4b7 14.0 landed
-
Set cutoff xmin more aggressively when vacuuming a temporary table.
- a7212be8b9e0 14.0 landed