Re: slow startup due to LWLockAssign() spinlock - Mailing list pgsql-hackers

From Tom Lane
Subject Re: slow startup due to LWLockAssign() spinlock
Date
Msg-id 654.1398357793@sss.pgh.pa.us
Whole thread Raw
In response to Re: slow startup due to LWLockAssign() spinlock  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: slow startup due to LWLockAssign() spinlock  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-24 11:02:44 -0400, Tom Lane wrote:
>> FWIW, I like the LWLockAssignBatch idea a lot better than the currently
>> proposed patch.  LWLockAssign is a low-level function that has no business
>> making risky assumptions about the context it's invoked in.

> I don't think LWLockAssignBatch() is that easy without introducing
> layering violations. It can't just return a pointer out of the main
> lwlock array that then can be ++ed clientside because MainLWLockArray's
> stride isn't sizeof(LWLock).

Meh.  I knew this business of using pointers instead of indexes would
have some downsides.

We could return the array stride ... kinda ugly, but since there's
probably only one consumer for this API, it's not *that* bad.  Could
wrap the stride-increment in a macro, perhaps.
        regards, tom lane



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: 9.4 Proposal: Initdb creates a single table
Next
From: Tom Lane
Date:
Subject: Re: 9.4 Proposal: Initdb creates a single table