Date: Tue, 26 May 2026 09:23:11 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: solai v <solai.cdac@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org
Subject: Re: problems with toast.* reloptions
Message-ID: <ahWsz2D9quWBgZ7s@nathan>
References: <aFRxC1W_kZU9OjJ9@nathan>
 <aFTB8bs_u5WyBReK@paquier.xyz>
 <aFnATDLLdP0m-fGb@nathan>
 <aFozXwRQu3LaDELy@paquier.xyz>
 <aFrUkYVyATVk2nsD@nathan>
 <afUd-A4CvaGc9se7@nathan>
 <afi-G3xIntN-pUjR@nathan>
 <afuzQuX17qpVugnY@nathan>
 <CAF0whuenaSkNNVXhk9207Q_fR57SLYbi_dV-p9Mer8=FjM7iwg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAF0whuenaSkNNVXhk9207Q_fR57SLYbi_dV-p9Mer8=FjM7iwg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ahWsz2D9quWBgZ7s%40nathan>
Precedence: bulk

On Tue, May 26, 2026 at 11:25:39AM +0530, solai v wrote:
> I tested the TOAST reloptions behavior locally on current HEAD and was
> able to reproduce the inheritance and RESET scenarios discussed in the
> thread.
> From my testing, explicit toast.reloptions behave independently from
> parent reloptions. After setting both parent and TOAST vacuum_truncate
> values, RESET(vacuum_truncate) on the parent table cleared only the
> parent reloption while the explicit TOAST reloption remained intact.
> I also tried applying the v1-0004 patch in a clean worktree, but most
> hunks in vacuum.c and autovacuum.c no longer apply cleanly against
> current HEAD due to code drift. From inspecting the rejected hunks, it
> looks like the patch approach was to dynamically combine parent and
> TOAST reloptions during VACUUM/autovacuum execution instead of copying
> inherited reloptions directly into the TOAST relation.

I humbly encourage you to read the rest of the thread.  In particular, I'm
curious whether anyone would object to removing the TOAST reloptions.

-- 
nathan