Re: Is it OK to perform logging while holding a LWLock?

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Is it OK to perform logging while holding a LWLock?
Date: 2026-03-04 01:29:17
Message-ID: CAD21AoBikzYa9Ss1pf_DVdoHw9rB+E51+oggdV9XY6rnPTSNMQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 3, 2026 at 4:15 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-03-04 01:31:14 Re: Trivial Fix: use palloc_array/repalloc_array for BufFile file arrays
Previous Message Chao Li 2026-03-04 01:16:12 Re: pg_resetwal.c: duplicate '0' in hex character set for -l option validation