Re: Disabling vacuum truncate for autovacuum

On Thu, Mar 20, 2025 at 11:13 AM Nathan Bossart <nathandbossart(at)gmail(dot)com>
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.