Re: problems with toast.* reloptions - Mailing list pgsql-hackers

>> Actually, I think there's a problem with this approach...

You're right. I forgot we can reset the table options. While we could
use a placeholder and resolve it on-demand, that seems like too much
work.

Hi all,

I started a conversation about TOAST table vacuum truncation parameter inheritance [1] and was pointed to this thread which I totally missed. I recently came across the issue where `vacuum_truncate` on TOAST tables wasn't being inherited even though the parent table had the setting, and the documentation mentioned that it should work [2]. I see that there are a lot of good conversations here already.

I'm curious to hear what folks think about the approach where we implement the inheritance logic directly in `vacuum_rel()` when `params.truncate == VACOPTVALUE_UNSPECIFIED`. This should address the point raised upthread about `vacuum_rel()` not looking up the main relation's reloptions when processing a TOAST  and also what I discovered in [1]. For instance it could be something like:

1. For TOAST tables: When no explicit `toast.vacuum_truncate` is set, scan `pg_class.reltoastrelid` to find the parent table and inherit its `vacuum_truncate` setting.
2. For manual VACUUM: Pass the final truncate decision from main table to TOAST table in the `toast_vacuum_params`
3. For autovacuum: The inheritance happens naturally since autovacuum calls `vacuum_rel()` for each relation independently

This basically teaches `vacuum_rel()` to consult the main relation's reloptions for TOAST tables, which was the core issue identified upthread. It handles both manual VACUUM and autovacuum scenarios in one place, without changing function signatures (which helps with potential backporting).

The execution-layer fix should also help us avoid the parameter contamination issues that were fixed in commit 661643dedad9 (I believe?), since we're doing the lookup fresh each time `vacuum_rel()` is called on a TOAST table.

I realize backporting might not be preferred given this issue has existed for a long time. However, that is precisely why I feel like it might be worth patching it because, at least per the docs, my understanding was that if `vacuum_truncate` is set on the parent table then it applies to the TOAST as well and I wonder if there are others in the same boat as well.

Would something like this focused approach (just teaching `vacuum_rel()` to look up parent reloptions for TOAST tables) could be a reasonable fix that complements the broader reloptions work discussed upthread for v19 and also backportable to v13 onwards?

I am happy to help with this and split out the changes as it makes sense as well.

Thanks
Shayon

[1] https://www.postgresql.org/message-id/CANqtF-pLHBDdNM-DifXQqVq%2BVWA3DTYOx4%2B3m2%2BTFJ1zDOZETg%40mail.gmail.com