MIME-Version: 1.0
References: 
 <CAGRkXqTo+aK=GTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw@mail.gmail.com>
 <aFLp9sMEHFHULOFx@nathan>
 <CAGRkXqTp9k_7X1OqqQSnVfoyGxAM3SQ083CcyaezBg9qQ8i+qg@mail.gmail.com>
 <aFRzYhOTZcRgKPLu@nathan> <aFS6m1tNH2sGMQ61@paquier.xyz>
In-Reply-To: <aFS6m1tNH2sGMQ61@paquier.xyz>
From: Junwang Zhao <zhjwpku@gmail.com>
Date: Fri, 20 Jun 2025 22:40:07 +0800
Message-ID: 
 <CAEG8a3+JeCt0xa_N9asAXxG6Xdc0tx-psJW4Od98bB8it1T8pg@mail.gmail.com>
Subject: Re: Fixes inconsistent behavior in vacuum when it processes multiple
 relations
To: Michael Paquier <michael@paquier.xyz>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
 shihao zhong <zhong950419@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAEG8a3%2BJeCt0xa_N9asAXxG6Xdc0tx-psJW4Od98bB8it1T8pg%40mail.gmail.com>
Precedence: bulk

On Fri, Jun 20, 2025 at 9:34=E2=80=AFAM Michael Paquier <michael@paquier.xy=
z> wrote:
>
> On Thu, Jun 19, 2025 at 03:30:26PM -0500, Nathan Bossart wrote:
> > After thinking about this some more, I'm wondering if it would be bette=
r to
> > pursue option (2) because it's a little less invasive (which is importa=
nt
> > because this will need to be back-patched).  In any case, we have a sim=
ilar
> > problem when recursing to the TOAST table, which can be fixed by copyin=
g
> > the params at the top of vacuum_rel().
> >
> > While testing out the attached patch, I noticed a couple of other
> > interesting problems in this area [0].
> >
> > [0] https://postgr.es/m/aFRxC1W_kZU9OjJ9%40nathan
>
> Hmm.  I like the simplicity of option 2) for the purpose the back
> branches and the post-feature-freeze v18.
>
> However, Option 1) would be my go-to option for HEAD (as of v19
> opening for business), but I think that we should harden the code more
> than suggested and treat all VacuumParams as purely input arguments
> rather keeping some pointers to it depending on the code path we are
> dealing with, so as no callers of these inner routines is surprised by
> changes that may happen internally.

I'd suggest just marking the VacuumParams *params with const, so
that the user can not change its content, or the compiler will error
out, it will force the user to make a copy if changes are needed.
I see vacuum_get_cutoffs already has the const signature.

Passing by const pointer is more efficient than passing by structure value.

> Hence, reading the code of v2,
> I'd suggest to apply the same rule to vacuum_get_cutoffs(),
> do_analyze_rel() and heap_vacuum_rel().  Except if I am missing
> something, it looks like all these calls should be OK with this new
> policy.  This implies also changing relation_vacuum() in tableam.h,
> which can be a HEAD-only change anyway.
> --
> Michael


--=20
Regards
Junwang Zhao