Hi, On Fri, Sep 18, 2026 at 2:19 PM Sami Imseih <[email protected]> wrote: > > Hi, > > While stress testing REPACK (CONCURRENTLY), I noticed that the current > "initializing" phase contains multiple operations that can wait indefinitely. > The transaction wait can be prolonged by long-running or prepared > transactions, or by another REPACK (CONCURRENTLY) operation that already has > an XID. Describing the whole phase as "expected to be very brief" [1] is > misleading.
Yeah, for REPACK (CONCURRENTLY), it could take a time before the scan starts. > > To make these waits visible and distinguish the work immediately before and > after the old transaction wait, three progress phases between > "initializing" and > the heap scan should be added. > > 1/ enabling logical decoding > > When wal_level is logical, or logical decoding is already enabled, this phase > is effectively instantaneous. Otherwise, REPACK waits for every running > process to acknowledge a ProcSignalBarrier. This normally finishes quickly, > but the barrier has no timeout and can take longer if a process does not > respond promptly. > > 2/ waiting for old transactions > > The snapshot builder waits for transactions with assigned XIDs to finish > before it can reach a consistent point. Right, these steps could take a time. Please note that if there is one logical slot or wal_level is set to 'logical', (1) is no-op. > > 3/ building initial snapshot > > REPACK obtains the initial snapshot from the decoding worker and prepares to > start copying the table. This separates the end of the transaction wait > from the start of the heap scan. While it's true that the logical decoding might need to read WAL records until the snapshot reaches a consistent state, I'm not sure that it can justify having its own phase. I think we can merge it to (2) and have something like a "initializing logical decoding" phase. > > This gives the following sequence: > > initializing (default, expected to be brief) > enabling logical decoding > waiting for old transactions > building initial snapshot > seq scanning heap / index scanning heap > > The attached patch has the worker publish its setup stage through shared > memory and signal the existing condition variable. > > Thoughts? I've not looked at the patch in depth yet but I agree with the general idea. Just to be clear, I think adding new phases would be a v20 item rather than an open item for v19. For v19, we can revise the documentation part only. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
