> On Jul 15, 2025, at 10:57 AM, Nathan Bossart <nathandboss...@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 see that 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 contamination is fixed, TOAST tables still
don't inherit parent vacuum_truncate settings during autovacuum operations, per
what'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 parameter value. [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 reloptions before calling
vacuum_rel(). This requires detecting TOAST tables and looking up parent
settings during parameter setup.
2) Execution layer fix: Add inheritance logic in vacuum_rel() when
params->truncate == VACOPT_TERNARY_DEFAULT. Detect TOAST tables and inherit
parent vacuum_truncate setting at the truncate decision point. Similar to a
very POC patch in the previous email.
For backporting, approach (2) works better since it doesn't change function
signatures. The isset_offset field needed for approach (1) only exists in v18+,
making proper explicit-vs-default detection impossible on older branches as you
pointed earlier 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 not preferable.
We can also implement both approaches together as well. I'm happy to help with
this and splitting out the changes as it makes sense.
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
