Re: Shared row locking

On Thu, 16 Dec 2004 21:54:14 -0300, Alvaro Herrera
<alvherre@dcc.uchile.cl> wrote:
>  Else, it will have to wait, using XactLockTableWait, for
>the first transaction in the array that is still running.  We can be
>sure that no one will try to share-lock the tuple while we check the
>btree because we hold an exclusive lock on the tuple's heap page's
>buffer.

Do you really want to XactLockTableWait while holding an exclusive
lock on a heap page?  Or are you going to release the lock before
entering the wait?

>Thanks to tablespaces, it's very easy to create special Relations that
>can be dealt with by standard buffer and storage manager, etc.

I don't get how tablespaces would help.

>The btree idea:
>- does not need crash recovery.  Maybe we could use a stripped down
>  version of nbtree.  This could cause a maintanibility nightmare.

It could be a nightmare if you simply duplicate and then modify the
code.  A better way would be to refactor nbtree to be able to handle
btrees with different properties:

. shared/private

. logged/non-logged

. flexible value data type.

>- can't hold more than 300 or so simultaneous lockers (because of value
>  length, limited to 1/3 of a page).  I doubt this is a real problem.

Or you store each lock as a separate index tuple.  If this is expected
to be a problem because of many repeating key vaules, nbtree should be
enhanced to support duplicate key compression, which might be a good
thing per se.

ServusManfred