On 04.02.2012 07:24, Jeff Janes wrote:
> Is it safe to assume that, under "#ifdef LWLOCK_STATS", a call to
> LWLockAcquire will always precede any calls to LWLockWaitUntilFree
> when a new process is started, to calloc the stats assays?>
> I guess it is right now, because the only user is WALWrite, which
> would never be acquired before WALInsert is at least once. But this
> doesn't seem very future proof.
Agreed, we can't count on that. There's no clear single point after a
process startup where the first lwlock is acquired. Out of curiosity, I
added an elog(LOG, ...) to that initialization code, to log which lwlock
is acquired first in a process. It depends on the process and
circumstances - here's the list I got:
BufFreeListLock
ShmemIndexLock
XidGenLock
ProcArrayLock
BgWriterCommLock
AutoVacuumLock
And that's probably not all, I bet you would acquire different locks
first with recovery, streaming replication etc.. I didn't test those.
Anyway, I added the initialization to LWLockWaitUntilFree now. Thanks!
> I guess the same complain could be logged against LWLockConditionalAcquire.
LWLockConditionalAcquire doesn't update the stats, so it's ok.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com