Hi,
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:
static bool
vacuum_rel(Oid relid, RangeVar *relation, VacuumParams *params)
{
...
/* Begin a transaction for vacuuming this relation */
StartTransactionCommand();
/*
* Need to acquire a snapshot to prevent pg_subtrans from being truncated,
* cutoff xids in local memory wrapping around, and to have updated xmin
* horizons.
*/
PushActiveSnapshot(GetTransactionSnapshot());
> Maybe you could make something like this work, but I think it'd still
> have to treat CLUSTER as a special case. Not sure it's worth it.
Why would CLUSTER need to be special cased? We'd precisely retain the
rows we need to, I think? Given that we'd exactly use the snapshot that
rules that determines which rows need to be retained?
Greetings,
Andres Freund
