public inbox for [email protected]  

help / color / mirror / Atom feed

From: David G. Johnston <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Gurjeet Singh <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Will Storey <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Postgres Hackers <[email protected]>
Subject: Re: Disabling vacuum truncate for autovacuum
Date: Thu, 20 Mar 2025 14:18:33 -0700
Message-ID: <CAKFQuwZJtw7Ojr=Z0xgA0G7BW6qSDkb0fMKgyaQULdOxHg_chA@mail.gmail.com> (raw)
In-Reply-To: <Z9xaroJSrS44HyKG@nathan>
References: <CABwTF4WFp-oNSm6utik6g-1HZBxijTJBcuX7BKD8MYqza+KMnw@mail.gmail.com>
	<[email protected]>
	<CABV9wwNagobmRMCxs0dKqWmKXaQTUQj+oOOTw=fsPAgbBfVhew@mail.gmail.com>
	<Z9g8a4HGLUcSo96v@nathan>
	<Z9ohFZtDaZnkch7u@nathan>
	<[email protected]>
	<Z9rlb0jgNLm8ULAB@nathan>
	<Z9rsMX5ZOL5E0cQy@nathan>
	<Z9wxuP1AY303wAxM@nathan>
	<CAKFQuwYKtEUYKS+18gRs-xPhn0qOJgM2KGyyWVCODHuVn9F-XQ@mail.gmail.com>
	<Z9xaroJSrS44HyKG@nathan>

On Thu, Mar 20, 2025 at 11:13 AM Nathan Bossart <[email protected]>
wrote:

> On Thu, Mar 20, 2025 at 09:59:45AM -0700, David G. Johnston wrote:
> > I get the need for this kind of logic, since we used a boolean for the
> > table option, but as a self-proclaimed hack it seems worth more comments
> > than provided here.  Especially pertaining to whether this is indeed
> > generic or vacuum_truncate specific.  It's unclear since both isset and
> > vacuum_truncate_set have been introduced.
>
> I'm happy to expand the comments, but...
>
> > If it is now a general property
> > applying to any setting then vacuum_truncate_set shouldn't be needed - we
> > should just get the isset value of the existing vacuum_truncate reloption
> > by name.
>
> the reason I added this field is because I couldn't find any existing way
> to get this information where it's needed.  So, I followed the existing
> pattern of adding an offset to something we can access.  This can be used
> for any reloption, but currently vacuum_truncate is the only one that does.
>
>
I'll come back to the comment if it's needed.  I was concerned about
dump/restore and apparently pg_dump has been perfectly capable of
determining whether the current catalog state for a reloption, even a
boolean, is unset, true, or false.  Namely, the following outcomes:

create table vtt (x int not null, y int not null);
CREATE TABLE public.vtt (
    x integer NOT NULL,
    y integer NOT NULL
);

alter table vtt set (vacuum_truncate = true);
CREATE TABLE public.vtt (
    x integer NOT NULL,
    y integer NOT NULL
)
WITH (vacuum_truncate='true');

alter table vtt reset (vacuum_truncate);

CREATE TABLE public.vtt (
    x integer NOT NULL,
    y integer NOT NULL
);

So my concern about dump/restore seems to be alleviated but then, why can
we not just do whatever pg_dump is doing to decide whether the current
value for vacuum_truncate is its default (and thus would not be dumped) or
not (and would be dumped)?

David J.

view thread (5+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Disabling vacuum truncate for autovacuum
  In-Reply-To: <CAKFQuwZJtw7Ojr=Z0xgA0G7BW6qSDkb0fMKgyaQULdOxHg_chA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox