Re: Shared row locking

On Thu, 16 Dec 2004 21:54:14 -0300, Alvaro Herrera
<alvherre(at)dcc(dot)uchile(dot)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.

Servus
Manfred