Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tvNIK-0045nu-HP for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Mar 2025 21:19:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tvNII-009Opy-N8 for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Mar 2025 21:19:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tvNII-009Opq-CB for pgsql-hackers@lists.postgresql.org; Thu, 20 Mar 2025 21:19:14 +0000 Received: from mail-oi1-x234.google.com ([2607:f8b0:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tvNIG-000Csm-16 for pgsql-hackers@postgresql.org; Thu, 20 Mar 2025 21:19:14 +0000 Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-3fcfc85f1f5so342912b6e.2 for ; Thu, 20 Mar 2025 14:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742505550; x=1743110350; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WD2MlJ9eBtmBBvUlyPe0uSeY/LdN46Z4p2nidC+xItE=; b=X654NItp8doH1ecVGY+PutzIf//uEY8x+9u6XHR8dSmLTJtqxjxupNRdQuEG+fkb+2 x9cN/4T/iuZ5zGHVY29P3a9w56HcVLkRs5T6CH7mXqYxAnffHlU3rWfScHg6/JriFIao WuNAjnk1Ab+SNcaEL92Q11EcKq53ojAmBgWPNcbsagIKnnq3OD1xRWVDB4adpfec5yXE tVHMnu9l/UTIxqa9D6IuDJuUsDWBFAyoLVX/5TnwavC5YH6pDbI9do3xVJ62Qw3xg8jC jq/s6lkSV6U2x1Ml2HUUK0poh2r1fiHQHgUYI9kdTLxJreyWyzwCWZ3udrpH6Vi/gb6G TenA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742505550; x=1743110350; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WD2MlJ9eBtmBBvUlyPe0uSeY/LdN46Z4p2nidC+xItE=; b=R+QhVC5nOlT6LfI308kiC7y6z4iqF36uRV3+Y2xVrHHpLzOZhGAtiA+1cT96Tp+Czt ShDgTwwFQUMG9McWHDbZFtOPBwRrOqlsOl7SYfeQxuJy7AOHbuV/88vrOLoR2O4dbkKc qH7RZ2gyw1QAtH8KGHhF238+s9RA0QhdB6h8zBWU6Dx00hnlvSUH4LMyXLtsAFQaMi6h Pg7ef9ueDsdjurt9E0BeVuEpnnpEZLasD8vo26Qqenpe4HwF7Ng6abTEz86ThKRgYUsG 2Pijslz30/qhoCVY/kVy8ec3qKJRwiNvp0n0uHgeZi2ykna6cgQS/e+W0H3a2jy+9lI2 Ka6g== X-Forwarded-Encrypted: i=1; AJvYcCXsW6uyi0Jp36hXigHc5yW7qaIQpLhCqogED6F0+9ZwAOGoUHmDB+52tL9i8E/zpvXnfCoiJxBH+ci3hkV8@postgresql.org X-Gm-Message-State: AOJu0YweB0XuVOTZLZcP79bLpvGL7Go0xBtpSXLljrZWDypCAhZNpQXk QNwaFgTck/kkg1nKuakglO+5lW5R4f4vdYiRWJvSIkAoJCqCtNWlva8SWALAOgHMhX0/T7D20ct UsRnJYN8QBzAHin2K5l7ks+OOKZw= X-Gm-Gg: ASbGncuB+NQTLfMorOypvmv0SqzCUq9QZ8KOy5AKgj+IrQPixOsH4Zc4QmNyOEcIjm6 z4DfETMspMVWoBT/MZMHCjniiBsHfCGAweiw/TjZdH0nziy61J7PULDK7h0m3yY7RhvdXt1xo6N 67cQLR2IXtAAKRZwiSYOyizJmg X-Google-Smtp-Source: AGHT+IFWaPUOd82x32ANQkZiP+VyElBDNb/5TJV27rI9U4ClIm4omCsWp/J1pFheOUu16VIfSEFFpP5sA5eAEZtre9c= X-Received: by 2002:a05:6808:3846:b0:3f8:30c1:ccc6 with SMTP id 5614622812f47-3febf702499mr547131b6e.8.1742505550291; Thu, 20 Mar 2025 14:19:10 -0700 (PDT) MIME-Version: 1.0 References: <6f2f2167f4be09e6ca9251c8f69dfe01809d68be.camel@cybertec.at> <88e3b55a-8ef8-4b53-8d71-6bfde1a07bc1@oss.nttdata.com> In-Reply-To: From: "David G. Johnston" Date: Thu, 20 Mar 2025 14:18:33 -0700 X-Gm-Features: AQ5f1JrBBzRQ7tWnORRPxKAt7qvLyrIyLk7n5wJWBi8-_fRNxtgQv3FxisGzqDE Message-ID: Subject: Re: Disabling vacuum truncate for autovacuum To: Nathan Bossart Cc: Fujii Masao , Robert Treat , Laurenz Albe , Gurjeet Singh , Andres Freund , Will Storey , Robert Haas , Postgres Hackers Content-Type: multipart/alternative; boundary="000000000000582a2e0630ccb07d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000582a2e0630ccb07d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2025 at 11:13=E2=80=AFAM Nathan Bossart 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 comment= s > > 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 relopti= on > > 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 doe= s. > > 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 =3D true); CREATE TABLE public.vtt ( x integer NOT NULL, y integer NOT NULL ) WITH (vacuum_truncate=3D'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. --000000000000582a2e0630ccb07d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 20, 2025 at 11:13=E2=80=AFAM Nathan Bossart &l= t;nathandbossart@gmail.com&= gt; wrote:
On Thu, Mar 20, 2025 a= t 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 commen= ts
> than provided here.=C2=A0 Especially pertaining to whether this is ind= eed
> generic or vacuum_truncate specific.=C2=A0 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 need= ed - we
> should just get the isset value of the existing vacuum_truncate relopt= ion
> by name.

the reason I added this field is because I couldn't find any existing w= ay
to get this information where it's needed.=C2=A0 So, I followed the exi= sting
pattern of adding an offset to something we can access.=C2=A0 This can be u= sed
for any reloption, but currently vacuum_truncate is the only one that does.=


I'll come back to the comment if it&= #39;s needed.=C2=A0 I was concerned about dump/restore and apparently pg_du= mp has been perfectly capable of determining whether the current catalog st= ate for a reloption, even a boolean, is unset, true, or false.=C2=A0 Namely= , the following outcomes:

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

alter table vtt set (vacuum_truncate =3D true);
CREATE TABLE= public.vtt (
=C2=A0 =C2=A0 x integer NOT NULL,
=C2=A0 =C2=A0 y integ= er NOT NULL
)
WITH (vacuum_truncate=3D'true');

alter table vtt reset (vacuum_truncate);

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

So my concern about dump/r= estore 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 it= s default (and thus would not be dumped) or not (and would be dumped)?

David J.

--000000000000582a2e0630ccb07d--