Re: Temporary tables versus wraparound... again - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Temporary tables versus wraparound... again
Date
Msg-id CAM-w4HN-9CAv3kFTKXiEktFXdfRgPJJmiYyXH4QWECTw5k7RnA@mail.gmail.com
Whole thread Raw
In response to Re: Temporary tables versus wraparound... again  (Greg Stark <stark@mit.edu>)
Responses Re: Temporary tables versus wraparound... again  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Thu, 31 Mar 2022 at 16:05, Greg Stark <stark@mit.edu> wrote:
>
> I haven't wrapped my head around multixacts yet. It's complicated by
> this same codepath being used for truncates of regular tables that
> were created in the same transaction.

So my best idea so far is to actually special-case the temp table case
in this code path. I think that's easy enough since I have the heap
tuple I'm about to replace.

In the temp table case I would just use the value Andres proposes.

In the "truncating table in same transaction it was created" case then
I would go ahead and use the expensive GetOldestMultiXactId() which
should be ok for that case. At least I think the "much higher rate"
comment was motivated by the idea that every transaction commit (when
temp tables are being used) is more frequent than any specific user
ddl.

It's not brilliant since it seems to be embedding knowledge of the
cases where this optimization applies in a lower level function. If we
think of some other case where it could apply it wouldn't be obvious
that it will have a cost to it. But it doesn't seem too terrible to
me.

An alternative would be to simply not adjust relminmxid for non-temp
tables at all. I guess that's not too bad either since these are
non-temp tables that autovacuum will be able to do anti-wraparound
vacuums on. And I get the impression mxids don't wraparound nearly as
often as xids?

-- 
greg



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Patches with failing tests in Commitfest
Next
From: Matthias van de Meent
Date:
Subject: Re: Restructure ALTER TABLE notes to clarify table rewrites and verification scans