On Wed, Aug 27, 2025 at 12:12 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Tue, Aug 26, 2025 at 2:32 AM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Tue, Aug 26, 2025 at 12:54 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > I've attached the updated patch that incorporated the comments and is
> > > rebased to the current HEAD.
> > >
> >
> > Thanks for the patch, please find a few comments concerning LOG messages:
>
> Thank you for reviewing the patch!
>
> >
> > 1)
> > slotsync worker gives LOG:
> > LOG: replication slot synchronization requires logical decoding to be enabled
> >
> > By this LOG message, the user might not know how to enable logical
> > decoding. Shall we add HINT/DETAIL similar to other places:
> > To enable logical decoding on standby, set "wal_level" >= "logical" or
> > create at least one logical slot on the primary server.
>
> Sounds good.
>
> >
> > 2)
> > When we try to create a logical slot on standby, it takes some time
> > until runnign-txns are logged on primary. During that wait-time, if we
> > drop logical slot on primary disabling logical_deocding on standby,
> > then slot-creation fails with:
> >
> > postgres=# SELECT pg_create_logical_replication_slot('st_slot2',
> > 'pgoutput', false, false, false);
> > ERROR: canceling statement due to conflict with recovery
> > DETAIL: User was using a logical replication slot that must be invalidated.
> >
> > Do we need to tweak the message a little bit as this new case is is
> > not the case of invalidation?
>
> I think this is the case of invalidation but why do you think it's not?
>
Sorry, I did not get. Which slot got invalidated? Primary's slot was
dropped and standby's slot did not even finish creation. So, I am
confused with the detail-message.
> >
> > 3)
> > When slot is invalidated on standby, we get message:
> >
> > LOG: invalidating obsolete replication slot "st_slot"
> > DETAIL: Logical decoding on standby requires "wal_level" >= "logical"
> > or to create at least one logical slot on the primary server.
> >
> > The DETAIL msg looks slightly odd. Shall we make it as:
> > Logical decoding on standby requires "wal_level" >= "logical" or at
> > least one logical slot on the primary server.
>
> Agreed.
>
> When testing the patch further, I found a bug in a race condition in
> case of aborting the activation process. In the attached latest
> version patch, I've fixed the bug and included the test case to the
> new TAP test.
>
> Regards,
>
> --
> Masahiko Sawada
> Amazon Web Services: https://aws.amazon.com
