Re: Fixes inconsistent behavior in vacuum when it processes multiple relations
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: shihao zhong <zhong950419@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-06-18T16:31:50Z
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
On Wed, Jun 18, 2025 at 11:15:31AM -0400, shihao zhong wrote: > I investigated the code and found a small bug with how we're passing > the VacuumParams pointer. > > The call flow is > ExecVacuum -> vacuum -> vacuum_rel > > The initial VaccumParams pointer is set in ExecVacuum > In vacuum_rel, this pointer might change because it needs to determine > whether to truncate and perform index_cleanup. Nice find! My first reaction is to wonder whether we should 1) also make a similar change to vacuum() for some future-proofing or 2) just teach vacuum_rel() to make a local copy of the parameters that it can scribble on. In the latter case, we might want to assert that the parameters don't change after calls to vacuum() and vacuum_rel() to prevent this problem from recurring. That leads me to think (1) might be the better option, although I'm not too wild about the subtlety of the fix. -- nathan