On Tue, Nov 15, 2011 at 8:33 PM, Alvaro Herrera <alvhe...@commandprompt.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers