Re: Add a test for index_rebuild_count of REPACK (CONCURRENTLY)

On Wed, Sep 16, 2026 at 04:30:16PM +0200, Alvaro Herrera wrote:
> I don't like this idea, because it adds no systematic mechanism to test
> the progress-report feature as a whole. I don't see why REPACK should
> be the place to start testing this. Also, injection points seem the
> wrong tool for the job, even if you can achieve testing an increment of
> a single progress counter within an existing test.

My feeling regarding v6-0003 echoes with yours. Using injection
points does not feel completely right to capture a dynamic state. We
could do something like a tracing facility perhaps? Run a set of SQL
commands, then check how much the progress has evolved over the full
sequence? To me, progress coverage should not just check one point in
time of the progress, but a succession of expected numbers. And this
does not have to involve concurrent activity.

Saying that, v16-0003 is only touching the module injection_points
with no footprint to the core backend. The exit callback is an
interesting thing to see, perhaps there could be a use for it. I am
not convinced by the oversized part to generate a forced NOTICE,
meaning duplication with the other existing callbacks.

> As I said in a reply to Fujii in the thread for the patch you replied to
> in pgsql-committers, I think we need to come up with a test framework
> specific to observing progress report counters. (Maybe, and I'm just
> braindumping here, have them in debug mode print out a line for each
> individual counter update that's made, so that a test file can
> observe/match those lines somehow). That's more work upfront, but it
> can allow us systematically test all the counters in a coherent way.

Yeah. I've just had my eyes on a test two hours ago, related to the
VACUUM progress view, that had the idea to plug into a TAP test an
injection point wait and a psql background session to check the
progress data. That feels bloated to me, just to check *one* state of
the progress report.
--
Michael