On Wed, Apr 27, 2005 at 11:19:34AM -0400, Tom Lane wrote:
> 1. If several transactions are holding shared lock on a row, and one
> of them wants to actually modify the row (or upgrade its lock to
> exclusive), it must wait for the others to end but can then do so.
> (I think the patch does this properly, but it's not documented in
> the comments.)
>
> 2. If a transaction is holding exclusive lock on a row, but then issues
> SELECT ... FOR SHARE on the row, its lock should remain exclusive.
> (I don't think the patch gets this right.)
I agree with both. The reason the patch does not deal with either is
because I didn't really think about those cases. My bad.
> Another issue that we may need to think about is that there is no
> protection against starvation: a would-be acquirer of a row lock
> could wait forever, because there isn't any mechanism preventing
> other processes from getting in front of him.
As I already mentioned in private email, I think this could be handled
via locking the MultiXactId itself, using the regular lock manager, just
before going to sleep. There's no harm in bloating the lock tables too
much because one backend can sleep on only one MultiXactId. So, any
would-be locker first gets the MultiXactId and then it sleeps on it, to
be awaken when the exclusive locker finishes.
This requires having an additional bogus relation like XactLockTable ...
I see this as introducing more cruft than I originally thought about
removing with. (Remember, I originally thought about getting rid of
XactLockTableWait and friends entirely.)
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Los dioses no protegen a los insensatos. Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)