Hi Bharath, v7 looks good here. Tested sequential, parallel on btree and GIN, all as the docs describe, including GIN reporting zero blocks and the reset clearing the previous index. Applies cleanly on 5e595d659fd, suites pass.
You were right that this needs an injection point, polling is not reliable when the value is set and reset around every index. One thing to add: the sequential path needs one too, not just the parallel workers, since lazy_vacuum_one_index sets and resets just as tightly. A single point in the per index loop covers both. Attached as two patches, take either half. v7-0003 is the injection point, v7-0004 a TAP test in test_misc. Runs in about a second, under both meson and make. Sanity check, it does fail if you take out the progress update. It does not cover the reset to 0, only that the value moves on. That needs a second point after the reset. Thanks, Shihao
v7-0003-Add-an-injection-point-in-the-per-index-vacuum-lo.patch
Description: Binary data
v7-0004-Add-a-TAP-test-for-per-index-vacuum-progress-repo.patch
Description: Binary data
v7-0001-Report-per-index-vacuum-progress-in-pg_stat_progr.patch
Description: Binary data
v7-0002-Remove-IndexVacuumInfo.report_progress.patch
Description: Binary data
