Re: vacuum_truncate configuration parameter and isset_offset

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: vacuum_truncate configuration parameter and isset_offset
Дата
Msg-id Z-GLN06DlD8p737q@nathan
обсуждение исходный текст
Ответ на Re: vacuum_truncate configuration parameter and isset_offset  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: vacuum_truncate configuration parameter and isset_offset
Re: vacuum_truncate configuration parameter and isset_offset
Список pgsql-hackers
On Mon, Mar 24, 2025 at 05:00:51PM +0100, Álvaro Herrera wrote:
> I don't understand why this shouldn't work exactly like
> vacuum_index_cleanup (cf. vacuum_rel lines 2170ff).  That would require
> no new mechanism.

I explained my reasons for not proceeding with that approach upthread [0].

I don't think there are any existing reloptions where there are two ways to
say "use the GUC."  For ones with corresponding GUCs, unsetting the storage
parameter is the mechanism for doing so.  vacuum_index_cleanup's AUTO
option would be the closest thing, but there's no backing GUC, so the
meaning of AUTO doesn't change unless someone changes the code.

TBH I'm not understanding the pushback for adding a way to determine
whether the storage parameter is actually set.  It's very simple, and it
seems like it could be useful elsewhere.  But more importantly, it allows
us to more closely match the behavior of the existing reloptions with GUCs,
and it prevents type mismatches (e.g., the reloption is an enum but the GUC
is a Boolean).

[0] https://postgr.es/m/Z-Fvmnf57z6zM8Ky%40nathan

-- 
nathan



В списке pgsql-hackers по дате отправления: