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