Hi,
On 2026-03-24 16:47:30 -0500, Nathan Bossart wrote:
> On Fri, Mar 20, 2026 at 04:32:48PM -0400, Andres Freund wrote:
> > On 2026-03-20 14:39:11 -0500, Nathan Bossart wrote:
> >> On Fri, Mar 20, 2026 at 12:27:49PM -0400, Andres Freund wrote:
> >> > Why wasn't it enough to add const markers and keep passing by pointer?
> >>
> >> IIRC the idea was to prevent similar problems in the future.
> >
> > Seems using const VacuumParams *params should suffice for that? I don't think
> > it's particularly likely that we'll accept code that casts the const away and
> > then later get hurt by that.
> >
> >> To avoid the extra #includes, we could instead use the back-patched version
> >> (e.g., commit 661643deda).
> >
> > I'd probably not go quite there, at least the params should largely be const,
> > with a local on-stack copy where we do need to modify.
>
> Here is a first try.
Thanks!
Looks reasonable on a skim.
> static bool
> -vacuum_rel(Oid relid, RangeVar *relation, VacuumParams params,
> +vacuum_rel(Oid relid, RangeVar *relation, const VacuumParams *params,
> BufferAccessStrategy bstrategy)
> {
> LOCKMODE lmode;
> @@ -2014,18 +2014,21 @@ vacuum_rel(Oid relid, RangeVar *relation, VacuumParams params,
> Oid save_userid;
> int save_sec_context;
> int save_nestlevel;
> + VacuumParams params_copy;
> VacuumParams toast_vacuum_params;
I'd maybe not name it _copy, but params_local or params_table or such, as
somehow it seems a bit odd to modify the copy. But I can't really explain why
it feels odd.
I wonder if more of the code in the function should be updated to use the
copy, otherwise it seems like it could more easily happen that a part of the
code not using the modified version is moved until after a modification, and
the code author assumes the modifications now have taken effect.
Greetings,
Andres Freund
