On Tue, Mar 3, 2026 at 4:15 PM Michael Paquier <[email protected]> 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
