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: v1-0001-logicalctl-release-LogicalDecodingControlLock-bef.patch
Description: Binary data

Reply via email to