| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: slow startup due to LWLockAssign() spinlock |
| Date: | 2014-04-24 16:43:13 |
| Message-ID: | 654.1398357793@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-04-24 16:53:11 | Re: 9.4 Proposal: Initdb creates a single table |
| Previous Message | David Fetter | 2014-04-24 16:35:18 | Re: 9.4 Proposal: Initdb creates a single table |