Re: FlexLocks

Excerpts from Robert Haas's message of mar nov 15 17:16:31 -0300 2011:
> On Tue, Nov 15, 2011 at 1:40 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > Which is the same locking avoidance technique we already use for sync
> > rep and for the new group commit patch.
>
> Yep...
>
> > I've been saying for some time that we should use the same technique
> > for ProcArray and clog also, so we only need to queue once rather than
> > queue three times at end of each transaction.
> >
> > 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.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support