Date: Fri, 20 Jun 2025 14:16:46 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: shihao zhong <zhong950419@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Fixes inconsistent behavior in vacuum when it processes multiple
 relations
Message-ID: <aFWznvZtYZ3VJxgi@nathan>
References: 
 <CAGRkXqTo+aK=GTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw@mail.gmail.com>
 <aFLp9sMEHFHULOFx@nathan>
 <CAGRkXqTp9k_7X1OqqQSnVfoyGxAM3SQ083CcyaezBg9qQ8i+qg@mail.gmail.com>
 <aFRzYhOTZcRgKPLu@nathan>
 <aFS6m1tNH2sGMQ61@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aFS6m1tNH2sGMQ61@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/aFWznvZtYZ3VJxgi%40nathan>
Precedence: bulk

On Fri, Jun 20, 2025 at 10:34:19AM +0900, Michael Paquier wrote:
> Hmm.  I like the simplicity of option 2) for the purpose the back
> branches and the post-feature-freeze v18.

Yeah, let's do this for now.

> 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.  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.

Sounds reasonable to me.

-- 
nathan