From f850779c908b8ef9afc4cbb41402e3c91853c845 Mon Sep 17 00:00:00 2001 From: Manu Date: Mon, 21 Sep 2026 20:59:40 -0300 Subject: [PATCH v1 4/5] Don't count the last key twice in a parallel GIN build's progress When the leader of a parallel GIN index build merges the workers' sorted tuples, it counts each tuple it reads in tuples_done, which so reaches tuples_total. It then counted once more when it flushed the entries buffered for the last key, which are tuples already counted, so the build ended with tuples_done one above tuples_total. Found with the PROGRESS_DEBUG tracing proposed in the same thread. Oversight in 8492feb98f6. --- src/backend/access/gin/gininsert.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/backend/access/gin/gininsert.c b/src/backend/access/gin/gininsert.c index aaef7020981..0e5ac87fc9a 100644 --- a/src/backend/access/gin/gininsert.c +++ b/src/backend/access/gin/gininsert.c @@ -1777,7 +1777,10 @@ _gin_parallel_merge(GinBuildState *state) ++numtuples); } - /* flush data remaining in the buffer (for the last key) */ + /* + * Flush data remaining in the buffer (for the last key). Its tuples were + * already counted in the progress report when they were read. + */ if (!GinBufferIsEmpty(buffer)) { AssertCheckItemPointers(buffer); @@ -1788,10 +1791,6 @@ _gin_parallel_merge(GinBuildState *state) /* discard the existing data */ GinBufferReset(buffer); - - /* Report progress */ - pgstat_progress_update_param(PROGRESS_CREATEIDX_TUPLES_DONE, - ++numtuples); } /* release all the memory */ -- 2.55.0