Re: FlexLocks

On Tue, Nov 15, 2011 at 8:33 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:

>> > I'm not really enthused by the idea of completely rewriting lwlocks
>> > for this. Seems like specialised code is likely to be best, as well as
>> > having less collateral damage.
>>
>> Well, the problem that I have with that is that we're going to end up
>> with a lot of specialized code, particularly around error recovery.
>> This code doesn't remove the need for ProcArrayLock to be taken in
>> exclusive mode, and I don't think there IS any easy way to remove the
>> need for that to happen sometimes.  So we have to deal with the
>> possibility that an ERROR might occur while we hold the lock, which
>> means we have to release the lock and clean up our state.  That means
>> every place that has a call to LWLockReleaseAll() will now also need
>> to cleanup ProperlyCleanUpProcArrayLockStuff().  And the next time we
>> need to add some kind of specialized lock, we'll need to do the same
>> thing again.  It seems to me that that rapidly gets unmanageable, not
>> to mention *slow*.  We need some kind of common infrastructure for
>> releasing locks, and this is an attempt to create such a thing.  I'm
>> not opposed to doing it some other way, but I think doing each one as
>> a one-off isn't going to work out very well.
>
> I agree.  In fact, I would think that we should look into rewriting the
> sync rep locking (and group commit) on top of flexlocks, not the other
> way around.  As Kevin says nearby it's likely that we could find some
> way to rewrite the SLRU (clog and such) locking protocol using these new
> things too.

I see the commonality between ProcArray locking and Sync Rep/ Group
Commit locking. It's basically the same design, so although it wasn't
my first thought, I agree.

I did originally write that using spinlocks, but that was objected to.
Presumably the same objection would hold here also, but if it doesn't
that's good.

Mixing the above 3 things together is enough for me; I just don't see
the reason to do a global search and replace on the lwlock name in
order to do that. This is 2 patches at same time, 1 we clearly need, 1
I'm not sure about. Perhaps some more explanation about the flexlocks
structure and design will smooth that unease.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services