Re: Fixes inconsistent behavior in vacuum when it processes multiple relations
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: shihao zhong <zhong950419@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-06-25T01:31:35Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rationalize handling of VacuumParams
- 2252fcd4276c 19 (unreleased) landed
-
Avoid scribbling of VACUUM options
- 65c3223f93a0 13.22 landed
- c079ba3fc2a4 14.19 landed
- 354944663df3 15.14 landed
- d187cabddadc 16.10 landed
- 2e0b5d252b10 17.6 landed
- 661643dedad9 18.0 landed
Attachments
- v5-0001-Refactor-handling-of-VacuumParams.patch (text/x-diff) patch v5-0001
- vacuum_opts_tests.txt (text/plain)
On Tue, Jun 24, 2025 at 11:30:13AM -0500, Nathan Bossart wrote: > On Tue, Jun 24, 2025 at 10:18:18AM +0900, Michael Paquier wrote: > > Knowing that I'm indirectly responsible for this mess, I would like to > > take care of that myself. Would that be OK for you? > > I would be grateful if you took care of it. Okay, applied the main fix down to v13 then. > +1 for this. I did something similar to verify the other bugs I reported, > and this seems far easier to maintain than potentially-unstable tests that > require lots of setup and that depend on secondary effects. After sleeping on this point, I have finished with this idea for tests down to v17, adding more coverage for v18 with the GUC vacuum_truncate and the "auto" mode of index_cleanup, while on it. v16 and older branches don't have tests, but I have checked the sanity of the two code paths using the tests attached for vacuum.sql and pgstattuple.sql, at least. Two truncation tests for the "false" cases were actually unstable. Sometimes the truncation may not happen even with an aggressive VACUUM. Anyway, it is enough to check the true case for the two code paths patched, even if it may not happen at 100%. I did not notice a problem with the index_cleanup case as long as we had enough pages in the TOAST btree index, requiring some runtime to load the entries, so the cost was annoying. Attached is the remaining patch for HEAD, planned once v19 opens, and the tests I have used on the back-branches as a txt to not confuse the CI, for reference. -- Michael