From: Álvaro Herrera <alvherre@kurilemu.de>
To: Manuel Reyes Bravo <manuelreyesbravo@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: Adam Lee <adam8157@gmail.com>
Subject: Re: Add a test for index_rebuild_count of REPACK (CONCURRENTLY)
Date: Thu, 17 Sep 2026 16:55:44 +0200
Message-ID: <aqv9k36EbP9tw16Z@alvherre.pgsql> (raw)
In-Reply-To: <CA+bCEdAN_QroNWJ2dFz0U10xD0OoFXtkHNLst1TjF38k7FdSWA@mail.gmail.com>
Hello,
On 2026-Sep-16, Manuel Reyes Bravo wrote:
> I would like to work on the framework for v20, if nobody else is.
Sounds good.
> Some facts that make it look tractable:
>
> - Every write to st_progress_param goes through backend_progress.c
> (pgstat_progress_update_param, _incr_param, _parallel_incr_param,
> _update_multi_param, plus start/end_command). There are 163 calls in
> 23 files, and none of them writes the array directly, so one hook
> there sees every update.
Yep.
> - There is precedent for the switch in the DEVELOPER_OPTIONS trace_*
> settings (trace_locks, trace_notify, trace_sort, ...).
I think those are all pretty archaic, so I wouldn't necessarily base a
design on them.
> Before writing anything, three questions, so that I build what you have
> in mind:
>
> 1. A runtime developer setting (say trace_progress, like trace_notify)
> or something compiled in only for debug builds (like LOCK_DEBUG
> around trace_locks)?
I think a compile option is enough. We'll want a buildfarm animal that
runs with that option set, but things set up in such a way that the
(limited amount of) debug code is compiled out for regular developer
builds, so that this doesn't cause "meson test" to be any slower.
> 2. Should tests read the lines from the server log in TAP tests, or
> from the client with client_min_messages in the regression suite?
> Counters such as blocks scanned vary between runs, so I assume a test
> would match phases and selected counters rather than every line.
No opinion on this. Maybe a good frame would be a TAP test that runs
REPACK/COPY/etc and then reads the debug output to see if the order of
phase switching is from A to B to C, and that block numbers in column
such-and-such are monotonically increasing within one phase, and that
they get back to 0 when changing to phase X, etc.
> 3. One line per call, or only when a value actually changes?
I think emitting a line when nothing has changed would be pointless
noise.
> The first users would be VACUUM and REPACK, including the two
> index_rebuild_count cases from this week.
Sure, as long as it's not restricted to only cover them.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
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: pgsql-hackers@postgresql.org
Cc: alvherre@kurilemu.de, manuelreyesbravo@gmail.com, pgsql-hackers@lists.postgresql.org, masao.fujii@gmail.com, adam8157@gmail.com
Subject: Re: Add a test for index_rebuild_count of REPACK (CONCURRENTLY)
In-Reply-To: <aqv9k36EbP9tw16Z@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox