Horton

Re: vacuum_truncate configuration parameter and isset_offset

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nikolay Shaplov <dhyan@nataraj.su>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@lists.postgresql.org, Robert Treat <rob@xzilla.net>, Fujii Masao <masao.fujii@oss.nttdata.com>, Albe <laurenz.albe@cybertec.at>, Gurjeet Singh <gurjeet@singh.im>, Will Storey <will@summercat.com>, Álvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-03-24T15:30:47Z
Lists: pgsql-hackers 
On Mon, Mar 24, 2025 at 8:26 AM Robert Haas <robertmhaas@gmail.com> wrote:

> On Mon, Mar 24, 2025 at 11:12 AM Nikolay Shaplov <dhyan@nataraj.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.