Re: Group commit, revised

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