From: | shihao zhong <zhong950419(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: problems with toast.* reloptions |
Date: | 2025-06-22 03:45:25 |
Message-ID: | CAGRkXqSt50z52SirOOZtFepWYNaOBx1GMN-kZ2ZHky3YPnT6vg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
I investigated that this afternoon and identified two potential
implementation approaches:
1) Create functions like resolve_toast_vac_opts() and
resolve_toast_rel_opts(). These would then be used in
table_recheck_autovac(), NeedsAutoVacTableForXidWraparound(), and
do_autovacuum() after the toast table check.
2) When updating a table's relopt, also update the relopt of its
associated TOAST table if it's not already set. Similarly, when
creating a new TOAST table, it would inherit the parent's relopt.
Option 2 seems more reasonable to me, as it avoids requiring customers
to manually resolve these options, when they have different settings
for the parent and TOAST tables."
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2025-06-22 09:56:15 | Re: [PATCH] Proposal to Enable/Disable Index using ALTER INDEX |
Previous Message | vignesh C | 2025-06-22 02:35:20 | Re: Logical Replication of sequences |