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
signature.asc
Description: PGP signature
