Re: Add REPACK progress phases for logical decoding setup

On Tue, Sep 22, 2026 at 2:20 PM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
>
> Thank you both for the review!
>
> > > 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.
>
> Good point. I added a point about effective_wal_level in the docs.
>
> > >
> > > 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.
>
> Sure. I also was not sure about this one. So I went ahead and
> put it under the "initializing logical decoding" step.
>
> > 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.
>
> Agreed, so I split it that way.
>
> v2-0001 is documentation only and is what I propose for the v19 open
> item. It adds more documentation about the "initializing" and "catch-up"
> phases for the steps that could be unbounded. It covers enabling logical
> decoding and initializing logical decoding, and the ACCESS EXCLUSIVE lock
> that is taken to perform the swap in the "catch-up" phase.
>
> v2-0002 is for v20 and adds only the "enabling logical decoding" and
> "initializing logical decoding" phases, moving the descriptions above into
> their own rows. It needs a catversion bump, which is not included.

Thank you for updating the patches!

I've reviewed the 0001 patch first as it's an open item. There are
some minor comments:

- expected to be very brief.
+ expected to be very brief, except for
+ <command>REPACK (CONCURRENTLY)</command>, where it also covers enabling
+ logical decoding and then initializing it. Enabling has nothing to do
+ if <xref linkend="guc-effective-wal-level"/> is already
+ <literal>logical</literal>; otherwise it waits for all backends to
+ acknowledge that they started writing the additional WAL information
+ that logical decoding requires. Initializing then waits for the

The logical decoding activation waits for all processes to acknowledge
it, not only backends.

+ transactions that had already been assigned a transaction ID to end, so
+ this phase can last as long as the longest of those transactions.

During the logical decoding initialization, the snapshot builder also
has to wait for transactions that started after the initialization
began (i.e., those that started while it was in the BUILDING_SNAPSHOT
state). So this phase can last longer than the longest of the
transactions that
were running when it started. How about rephrasing it as follows?

expected to be very brief, except for
<command>REPACK (CONCURRENTLY)</command>, where it also covers enabling
logical decoding and then initializing it. Enabling has nothing to do
if <xref linkend="guc-effective-wal-level"/> is already
<literal>logical</literal>; otherwise it waits for all processes to
acknowledge that they started writing the additional WAL information
that logical decoding requires. Initializing then waits for the
transactions that have been assigned a transaction ID to end,
including ones that started while this wait was in progress, so this
phase can last longer than the longest transaction running when the
command started.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com