From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: More aggressive vacuuming of temporary tables |
Date: | 2020-09-08 21:47:53 |
Message-ID: | 20200908214753.su4verpdtldxzif4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-09-08 15:24:54 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-09-08 22:13:30 | Re: default partition and concurrent attach partition |
Previous Message | Tom Lane | 2020-09-08 21:39:24 | SIGQUIT handling, redux |