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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
