From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 21:28:14 |
Message-ID: | 20140424212814.GD32057@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-04-24 12:43:13 -0400, Tom Lane wrote:
> 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.
I think I am just going to wait for 9.5 where I sure hope we can
allocate the buffer lwlocks outside the main array...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-04-24 22:26:17 | Re: Clock sweep not caching enough B-Tree leaf pages? |
Previous Message | Alvaro Herrera | 2014-04-24 20:21:14 | Re: assertion failure 9.3.4 |