Re: problems with toast.* reloptions

On Fri, Jun 20, 2025 at 11:05:37AM +0900, Michael Paquier wrote:
> On Thu, Jun 19, 2025 at 03:20:27PM -0500, Nathan Bossart wrote:
>> I think we need to do something like the following to fix this:
>> 
>> * Teach autovacuum to combine the TOAST reloptions with the main relation's
>>   when processing TOAST tables (with the toast.* ones winning if both are
>>   set).
>> 
>> * Teach autovacuum to resolve reloptions for parameters like
>>   vacuum_truncate instead of relying on vacuum_rel() to fill it in.
> 
> These two points make sense here, yes.
> 
>> * Have vacuum_rel() send the main relation's reloptions when recursing to
>>   the TOAST table so that we can combine them there, too.
> 
> For the case of a manual VACUUM on the main table, where the TOAST
> table is treated as a secondary citizen, that makes sense as well,
> yes.

Here is a very rough proof-of-concept patch set for this.  AFAICT there are
a few options we cannot fix on the back-branches because there is no way to
tell whether it is set or has just picked up the default.  On v18 and
newer, we could use isset_offset, but that doesn't exist on older versions.
(I haven't looked closely, but I'm assuming that back-patching isset_offset
isn't an option.)

I would like to explore the "option 2" from upthread [0] for v19.  I think
that is a better long-term solution, and it may allow us to remove the
table_toast_map in autovacuum.

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

-- 
nathan