Re: vacuum_truncate configuration parameter and isset_offset

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nikolay Shaplov <dhyan(at)nataraj(dot)su>, 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:30:47
Message-ID: CAKFQuwbFrjzh+RXsy49qZZExc32S7r1+q1EtCCTpe4QBAMjX6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 24, 2025 at 8:26 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Mar 24, 2025 at 11:12 AM Nikolay Shaplov <dhyan(at)nataraj(dot)su> wrote:
> > Nobody would guess that
> >
> > ALTER TABLE test SET (vacuum_truncate=false);
> > means "off"
> >
> > and
> > ALTER TABLE test RESET (vacuum_truncate);
> > means "system_default"
> >
> > This will lead to a lot of confusion.
>
> I agree that this confuses people, 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.
>
>
+1

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2025-03-24 15:41:35 Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Previous Message Heikki Linnakangas 2025-03-24 15:25:54 Re: Snapshot related assert failure on skink