Re: vacuum_truncate configuration parameter and isset_offset

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Treat <rob(at)xzilla(dot)net>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Albe <laurenz(dot)albe(at)cybertec(dot)at>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Will Storey <will(at)summercat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: vacuum_truncate configuration parameter and isset_offset
Date: 2025-03-24 21:20:01
Message-ID: Z-HMgcIWbvVCrrzW@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 24, 2025 at 11:27:15PM +0300, Nikolay Shaplov wrote:
> В письме от понедельник, 24 марта 2025 г. 23:04:39 MSK пользователь Nathan
> Bossart написал:
>> But again, I don't see any strong reason why we must change all such
>> reloptions.
>
> Because code of the engine should be consistent. We can't have two different
> ways to do same thing. If we have isset flag, we should go for it everywhere,
> where isset logic exists. Or do not use it at all. Other ways will lead us to
> a much bigger mess, then we have today.

I don't disagree that it might be desirable for all reloptions with
corresponding GUCs to use isset_offset, but I am not following why this is
critically important. The out-of-range default approach has worked just
fine for years, and I'm not aware of any reason that isset_offset isn't
also a suitable solution.

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2025-03-24 21:23:18 Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Previous Message Tom Lane 2025-03-24 21:10:12 Re: Logging which local address was connected to in log_line_prefix