Date: Mon, 23 Jun 2025 10:38:40 -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: <aFl1AB9ofnQrrckV@nathan>
References: 
 <CAGRkXqTo+aK=GTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw@mail.gmail.com>
 <aFLp9sMEHFHULOFx@nathan>
 <CAGRkXqTp9k_7X1OqqQSnVfoyGxAM3SQ083CcyaezBg9qQ8i+qg@mail.gmail.com>
 <aFRzYhOTZcRgKPLu@nathan>
 <aFS6m1tNH2sGMQ61@paquier.xyz>
 <aFWznvZtYZ3VJxgi@nathan>
 <aFiWUzW8VChL-hGg@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aFiWUzW8VChL-hGg@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/aFl1AB9ofnQrrckV%40nathan>
Precedence: bulk

On Mon, Jun 23, 2025 at 08:48:35AM +0900, Michael Paquier wrote:
> Anyway, here is an attempt at leaning all that.  I am really tempted
> to add a couple of const markers to force VacuumParams to be in
> read-only mode, even if it means doing so for vacuum() but not touch
> at vacuum_rel() where we double-check the reloptions for the truncate
> and index cleanup options.  That would be of course v19-only material.
> Thoughts or opinions?

Is the idea to do something like this for v19 and this [0] for the
back-branches?

I think the recurse-to-TOAST-table case is still broken with your patch.
We should probably move the memcpy() for toast_vacuum_params to the very
top of vacuum_rel().  Otherwise, your patch looks generally reasonable to
me.

[0] https://postgr.es/m/aFRzYhOTZcRgKPLu%40nathan

-- 
nathan