Re: Progress reporting: a debug trace and a test framework

On Mon, Oct 05, 2026 at 10:29:09PM -0300, Manu wrote:
> While rebasing, the completeness check in 0006 flagged that commit
> 1378aa13430 ("Report per-index vacuum progress in pg_stat_progress_vacuum")
> added PROGRESS_VACUUM_CURRENT_INDEX_RELID without it being described in the
> spec that the test reads from progress.h. v4 classifies it -- it is the
> OID of the index a worker is currently processing, so a free value.
> Catching that kind of drift, a new counter that nothing describes or
> tests, is what the check is for.

While posting such things, you may want to create a new thread instead
of replying to an existing thread and changing the subject of the
previous thread to what you want to send: this breaks thread flows.

> Nothing else changed since v3: the four bug fixes in 0001-0004 and the
> PROGRESS_DEBUG trace in 0005 are the same.

Ah, yeah, v4-0001 and v4-0004 look like mistakes. While we're on it,
there is an extra gap in _gin_process_worker_data(): in the case of
GinBufferShouldTrim(), we should surely increment bs_numtuples after
tuplesort_putgintuple().

v4-0002 looks wrong to me; you are manipulating the report resets
even under !progress, and you surely should not do that.

I don't see the point of v4-0003 as well: on the next pass the
counters will be updated anyway, or we should see a reset of the
counters shortly enough.

All these feel cosmetic to me, even if from what I can see they could
lead to sporadic blips. If I follow that correctly, heap goes a short
time at 100% of blocks done vs total, while gin could go over 100% of
done vs total. Annoying, but not critical in any way.
--
Michael