| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Is it OK to perform logging while holding a LWLock? |
| Date: | 2026-02-11 03:00:53 |
| Message-ID: | A3EEC9DA-CCA0-45C5-B81C-DD5A0B1F4F01@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
As $SUBJECT says, my understanding is no. I think LWLocks are generally only held for a very short duration, like a few CPU cycles to read or modify some shared data, so operations that might involve additional overhead (like logging, which could touch I/O paths) are better done outside the lock section when possible.
I don’t find a concrete reference or documentation explicitly stating this, but it seems to be a common convention in the codebase.
Am I missing something here? Or are there cases where doing so is considered acceptable?
I’m asking because I noticed that in DisableLogicalDecoding(), we emit an ereport() before releasing LogicalDecodingControlLock:
```
if (!in_recovery)
ereport(LOG,
errmsg("logical decoding is disabled because there are no valid logical replication slots"));
LWLockRelease(LogicalDecodingControlLock);
```
In this particular case, the ereport() doesn’t seem to depend on the lock at all, so it looks safe to release the lock first and then log.
So, If my understanding is correct, please see the attached patch. Otherwise, feel free to ignore it.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-logicalctl-release-LogicalDecodingControlLock-bef.patch | application/octet-stream | 1.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-02-11 03:16:07 | Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct |
| Previous Message | Chao Li | 2026-02-11 02:32:32 | Re: brin: Remove duplicate initialization in initialize_brin_buildstate() |