Re: effective_multixact_freeze_max_age issue
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "Bossart, Nathan" <bossartn@amazon.com>, Jeremy Schneider <schneider@ardentperf.com>
Date: 2022-08-29T22:40:13Z
Lists: pgsql-hackers
On Mon, Aug 29, 2022 at 10:25:50AM -0700, Peter Geoghegan wrote: > On Sun, Aug 28, 2022 at 4:14 PM Nathan Bossart <nathandbossart@gmail.com> wrote: >> The idea seems sound to me, and IMO your patch simplifies things nicely, >> which might be reason enough to proceed with it. > > It is primarily a case of making things simpler. Why would it ever > make sense to interpret age differently in the presence of a long > running transaction, though only for the FreezeLimit/MultiXactCutoff > cutoff calculation? And not for the closely related > freeze_table_age/multixact_freeze_table_age calculation? It's hard to > imagine that that was ever a deliberate choice. > > vacuum_set_xid_limits() didn't contain the logic for determining if > its caller's VACUUM should be an aggressive VACUUM until quite > recently. Postgres 15 commit efa4a9462a put the logic for determining > aggressiveness right next to the logic for determining FreezeLimit, > which made the inconsistency much more noticeable. It is easy to > believe that this was really just an oversight, all along. Agreed. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
-
Derive freeze cutoff from nextXID, not OldestXmin.
- c3ffa731a5f9 16.0 landed
-
Consolidate VACUUM xid cutoff logic.
- efa4a9462a07 15.0 cited
-
Fix bug that could try to freeze running multixacts.
- 6bda2af039d4 13.0 cited
-
Teach autovacuum about multixact member wraparound.
- 53bb309d2d5a 9.5.0 cited