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