Re: Debugging deadlocks

>>I suppose there must be reasons not to do this, but have you considered
>>using the "slack" space (empty space) in an ordinary table "heap" page
>>to store share-locks on the tuples in that page? (If not enough space
>>is available then you would still need to use the spilled-to-disk btree
>>structure.)
>>
>>
>
>No, I hadn't considered it. However this seems hard to do, because the
>"slack space" does not have a start point; on each page, elements
>(tuples) grow from the back to the front, while element pointers grow
>in the reverse direction. So I don't see how would this be done.
>
>
Would it work for an updater, who finds that the locks list (currently
located in the middle of the empty space) is "in the way" of a new tuple
that he wants to insert, to take some kind of lock, move the whole list
up or down (spilling some of these locks to the disk if no more space is
available), and release it again?

Could the lock(s) on a particular tuple be tacked onto the end of that
tuple? (I think tuples are stored variable-width anyway, aren't they?)
I suppose this is conceptually equivalent to adding a variable width
system column which gets TOASTED when it gets too wide. I suppose this
would make taking a lock as expensive as doing an update, though, right?

Paul Tillotson