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

From shihao zhong
Subject Re: problems with toast.* reloptions
Date
Msg-id CAGRkXqSt50z52SirOOZtFepWYNaOBx1GMN-kZ2ZHky3YPnT6vg@mail.gmail.com
Whole thread Raw
List 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."



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
Next
From: Junwang Zhao
Date:
Subject: Re: [PATCH] Proposal to Enable/Disable Index using ALTER INDEX