Thread

Re: Adding REPACK [concurrently]

Masahiko Sawada <sawada.mshk@gmail.com> — 2026-05-08T23:22:15Z

On Fri, May 8, 2026 at 6:58 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2026-May-08, Amit Kapila wrote:
>
> > On Wed, May 6, 2026 at 1:55 PM Antonin Houska <ah@cybertec.at> wrote:
>
> > Some issues/inefficiencies regarding this fix and base code related to
> > db-specific snapshots built during decoding: [...]
>
> Thanks for spending time reviewing this code.  I think none of these
> problems are fundamental in nature, but they are obviously worth
> addressing for 19.  If we hit some roadblock, we can still revert only
> db-specific snapshots.
>

I'm still studying REPACK (CONCURRENTLY), and I have a question about
db-specific decoder; as far as I read the codes, any decoding plugin
can use db-specific decoder by setting need_shared_catalog=false but
should we prevent such slots from being created on standbys? I'm a bit
concerned that plugin developers inadvertently set
need_shared_catalog=false in the startup callback and users would
create such slots on standbys.  For instance, if we create a logical
slot with pgrepack plugin on the standby, we would get an assertion
failure as the db-specific decoder tries to call LogStandbySnapshot()
via SnapBuildProcessRunningXacts(). Even if we add
!RecoveryInProgress() check there, the db-specific decoder on standbys
requires for the primary server to run a REPACK (CONCURRENTLY).

Regards,

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