I previously wrote:
> 5) A mutex/spinlock that was stored in the index could be
> acquired by the scan code like this:
>
> buf = ReadBuffer(rel, blkno); /* pin next page
> */
>
> SpinLockAcquire( indexSpecificMutex ); /* lock the index
> reorg mutex */
>
> LockBuffer(buf, BUFFER_LOCK_UNLOCK); /* release lock on
> current page */
> LockBuffer(buf, BT_READ); /* lock next page */
>
> SpinLockRelease( indexSpecificMutex ); /* unlock the index
> reorg mutex */
>
> ReleaseBuffer(buf); /* now release pin on
> previously current page */
>
> 6) The same index specific mutex/spinlock could be used for
> the merge code surrounding only the acquisition of the four
> page locks. This would obviate any problems with scans and
> page merges, since the lock acquisition for the merge could
> never occur while a scan was between pages.
>
> Further, with the reordering, the spinlock for the scan code
> doesn't seem particularly onerous since it would be
> surrounding only two LWLock calls. To reduce the overhead to
> an absolute minimum for the scan case these could be pushed
> down into a new IW call (probably necessary since the
> LockBuffer, ReleaseBuffer code does some error checking and
> such that one wouldn't want in code guarded by a mutex.
I forgot to mention that the mutex would have to be release in the event
the next page lock could not be immediately acquired just after the
addition of the scan process to the lock waiters list to avoid blocking
all scans and probably causing severe deadlock problems.
- Curtis