Re: vacuum_truncate configuration parameter and isset_offset

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(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>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: vacuum_truncate configuration parameter and isset_offset
Date: 2025-03-24 15:45:00
Message-ID: 3089108.taCxCBeP46@thinkpad-pgpro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от понедельник, 24 марта 2025 г. 18:25:44 MSK пользователь Robert
Haas написал:

> > and
> > ALTER TABLE test RESET (vacuum_truncate);
> > means "system_default"
> >
> > This will lead to a lot of confusion.
>
> I agree that this confuses people,
Though a bit more, I think that as a user I would prefer to be able to
explicitly set "system_defaults" value. If I have not set any, most probably I
do not care, or have not thought about it. But if I set option to
"system_defaults" then I do it intentionally and have some good reasons for
it.

> but I don't think it's more
> confusing here than for other vacuum reloptions. I have seen people
> try to unset vacuum reloptions by using SET to configure them to the
> default value rather than by using RESET to remove them. But then
> later they change the system default and that table is still nailed to
> the old default. I always find myself slightly bemused by this,
> because it doesn't seem that hard to me to figure out how it actually
> works, but it's definitely a real issue. However, I don't see why the
> issue is any more acute for this parameter than any other, and it
> certainly does not seem like a good idea to make this parameter work
> differently from the other ones.

May be I can agree with you. But this does not explain why we should switch
boolean from two possible values into three... It can't have three values for
any practical reason. This should not be boolean anymore in this case.

--
Nikolay Shaplov aka Nataraj
Fuzzing Engineer at Postgres Professional
Matrix IM: @dhyan:nataraj.su

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2025-03-24 15:45:36 Modify SHOW to display reloptions by accepting table-qualified names.
Previous Message Tom Lane 2025-03-24 15:44:13 Re: High memory usage in CachedPlan for large IN clauses in partitioned table updates