On Fri, May 8, 2026 at 6:58 AM Alvaro Herrera <[email protected]> wrote: > > On 2026-May-08, Amit Kapila wrote: > > > On Wed, May 6, 2026 at 1:55 PM Antonin Houska <[email protected]> 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
