Re: Add REPACK progress phases for logical decoding setup

Hi Sami,

I checked v2. Both patches apply and build clean, and the two claims
the new documentation makes that a reader cannot easily verify are
true. Measurements below are on the tree with PROGRESS_DEBUG, which
logs every phase value a backend emits, so the sequences are recorded
rather than sampled.

1. "This phase is skipped when not in concurrent mode"

REPACK t phases emitted: 1 6 7 8
REPACK (CONCURRENTLY) t phases emitted: 9 10 1 7 5 6 8

9 and 10 appear only in the concurrent case, and they come before the
heap scan, as the table now describes.

2. catch-up "also covers waiting for the ACCESS EXCLUSIVE lock needed
to swap the files, so a command blocked by a conflicting lock stays
in this phase"

With a session holding the table open in a transaction and a REPACK
(CONCURRENTLY) behind it:

pg_stat_progress_repack.phase catch-up
pg_stat_activity Lock / relation

So it does stay in catch-up, and that is where an operator will find a
blocked REPACK.

3. The catversion bump

Confirmed missing, as you noted: catversion.h is still 202609152 in
v2-0002. Only flagging it so it does not get lost.

4. One thing the documentation still does not say

The phase table lists the phases in an order that is not the order
they happen in. From the run above, the concurrent sequence is

9 (enabling logical decoding)
10 (initializing logical decoding)
1 (seq scanning heap)
7 (rebuilding index)
5 (catch-up)
6 (swapping relation files)
8 (final cleanup)

but the table lists "rebuilding index" after "swapping relation
files", near the end. This is pre-existing - build_new_index() sets
REBUILD_INDEX and REPACK (CONCURRENTLY) reaches it before catch-up -
and not something v2 introduces. Since 0001 is specifically about
making this table less misleading for someone watching a long REPACK,
it might be worth either ordering the rows the way the phases occur or
saying that the order of the rows is not the order of execution.

Our own progress test module (the invariant checker from the debug
framework thread) passes on v2 without any change: it derives the
phase values from progress.h by prefix, so it picked up 9 and 10 on
its own.

Regards,
Manu