Re: More aggressive vacuuming of temporary tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: More aggressive vacuuming of temporary tables
Date: 2020-09-08 22:13:58
Message-ID: 1852427.1599603238@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> 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:

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-08 22:37:05 Re: VACUUM (INTERRUPTIBLE)?
Previous Message Alvaro Herrera 2020-09-08 22:13:30 Re: default partition and concurrent attach partition