On Tue, Mar 3, 2026 at 4:15 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Mar 03, 2026 at 12:48:26PM -0800, Masahiko Sawada wrote:
> > Also, if we reverse the ereport() and LWLockRelease() in the specific
> > example in logicalctl.c, it would happen that a concurrent logical
> > decoding activation writes the log "logical decoding is enabled upon
> > creating a new logical replication slot" before the deactivation
> > "logical decoding is disabled because there are no valid logical
> > replication slots", confusing users since the logical decoding is
> > active even though the last log saying "logical decoding is disabled".
>
> I don't really understand why we need to care about changing these
> code paths. LWLocks are not bound to requirements like avoiding
> elog() or Postgres-specific calls while being hold, so what we are
> doing is basically fine. None of the code paths changed here are
> relevant performance-wise, as well. Hence, why caring at all with
> such changes?
We were concerned about potential deadlocks that might happen if we do
something (including system catalog lookups etc.) in errcontext.
However, as I mentioned in the previous email[1], these changes are
not necessary as we don't need to be concerned about deadlocks in this
case.
Regards,
[1] https://www.postgresql.org/message-id/CAD21AoDgyTdJgd1Ep1Dgu12Wa7JXzp78f%2B8-BC%3DMzeT1qt_9hA%40mail.gmail.com
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
