public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: shihao zhong <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Fixes inconsistent behavior in vacuum when it processes multiple relations
Date: Tue, 24 Mar 2026 23:29:52 -0400
Message-ID: <loig4i4hc4vuybn6uv6e2kgqm37sebbzujkrvdf6uhbxq5dsfm@7wbkmucts3eu> (raw)
In-Reply-To: <acMGcoUwA9CiPPU1@nathan>
References: <aFl1AB9ofnQrrckV@nathan>
	<[email protected]>
	<aFrSlSz9fi47j5Sr@nathan>
	<[email protected]>
	<aFwT31Rw-Oj-bgO9@nathan>
	<[email protected]>
	<rzxpxod4c4la62yvutyrvgoyilrl2fx55djaf2suidy7np5m6c@3l2ln476eadh>
	<ab2iXwhRe3fFNPfp@nathan>
	<aglpy2jbnb75vufdx6hqkgokquzmoshcbnuxlcxhum4k7tyi7m@27m4hbxo2u2g>
	<acMGcoUwA9CiPPU1@nathan>

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

view thread (32+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Fixes inconsistent behavior in vacuum when it processes multiple relations
  In-Reply-To: <loig4i4hc4vuybn6uv6e2kgqm37sebbzujkrvdf6uhbxq5dsfm@7wbkmucts3eu>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox