Re: TOAST table vacuum truncation parameter inheritance bug (?) in autovacuum

> On Jul 15, 2025, at 10:57 AM, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> At a quick glance, this sounds very similar to the problems discussed in
> the following threads:
>
>     https://postgr.es/m/CAGRkXqTo%2BaK%3DGTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw%40mail.gmail.com
>     https://postgr.es/m/aFRxC1W_kZU9OjJ9%40nathan

Hi Nathan,

Thanks for the pointer to the other threads. I totally missed those changes, but caught up on the VacuumParams work and
seethat the parameter scribbling issue has been resolved in 661643dedad9. 

That said, I believe the TOAST inheritance issue I mentioned still remains. While the multi-table parameter
contaminationis fixed, TOAST tables still don't inherit parent vacuum_truncate settings during autovacuum operations,
perwhat's mentioned in the documentation IIUC: 

> If a table parameter value is set and the equivalent toast. parameter is not, the TOAST table will use the table's
parametervalue. [1] 

Happy to move this to other thread, if it makes more sense, let me know.

My general thinking is that perhaps there are two approaches so far -

1) Autovacuum parameter resolution: Modify do_autovacuum() and table_recheck_autovac() to combine parent and TOAST
reloptionsbefore calling vacuum_rel(). This requires detecting TOAST tables and looking up parent settings during
parametersetup. 

2) Execution layer fix: Add inheritance logic in vacuum_rel() when params->truncate == VACOPT_TERNARY_DEFAULT. Detect
TOASTtables and inherit parent vacuum_truncate setting at the truncate decision point. Similar to a very POC patch in
theprevious email. 

For backporting, approach (2) works better since it doesn't change function signatures. The isset_offset field needed
forapproach (1) only exists in v18+, making proper explicit-vs-default detection impossible on older branches as you
pointedearlier in one of the threads too I believe.  

I personally would love to see this get fixed in from v13 to V18 and also in v19, but I understand if backporting is
notpreferable. 

We can also implement both approaches together as well. I'm happy to help with this and splitting out the changes as it
makessense.  

Let me know if you think this makes sense and if you have any thoughts on which direction makes more sense?

Thank you
Shayon

[1] https://www.postgresql.org/docs/current/sql-createtable.html#RELOPTION-VACUUM-TRUNCATE