Horton
Menu

Re: Disabling vacuum truncate for autovacuum

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Robert Treat <rob@xzilla.net>, Laurenz Albe <laurenz.albe@cybertec.at>, Gurjeet Singh <gurjeet@singh.im>, Andres Freund <andres@anarazel.de>, Will Storey <will@summercat.com>, Robert Haas <robertmhaas@gmail.com>, Postgres Hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-20T21:31:33Z
Lists: pgsql-hackers, pgsql-general 
On Thu, Mar 20, 2025 at 02:18:33PM -0700, David G. Johnston wrote:
> 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)?

pg_dump looks at the pg_class.reloptions array directly.  In the vacuum
code, we look at the pre-parsed rd_options (see RelationParseRelOptions()
in relcache.c), which will have already resolved vacuum_truncate to its
default value if it was not explicitly set.  We could probably look at
pg_class.reloptions directly in the vacuum code if we _really_ wanted to,
but I felt that putting this information into rd_options was much cleaner.

-- 
nathan

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Expand comment for isset_offset.

  2. Add vacuum_truncate configuration parameter.