> > START_/END_CRIT_SECTION is mostly CritSectionCount++/--.
> > Recording could be made as 
> > LockedSpinLocks[LockedSpinCounter++] = &spinlock
> > in pre-allocated array.
> 
> Yeah, I suppose.  We already do record locking of all the fixed
> spinlocks (BufMgrLock etc), it's just the per-buffer spinlocks that
> are missing from that (and CRIT_SECTION calls). Would it be 
> reasonable to assume that only one buffer spinlock could be held
> at a time?

No. UPDATE holds two spins, btree split even more.
But stop - afair bufmgr remembers locked buffers, probably
we could just add XXX_CRIT_SECTION to LockBuffer..?

Vadim

Tue, 9 Jan 2001 10:50:40 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Quite strange crash 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> Yeah, I suppose.  We already do record locking of all the fixed
>> spinlocks (BufMgrLock etc), it's just the per-buffer spinlocks that
>> are missing from that (and CRIT_SECTION calls). Would it be 
>> reasonable to assume that only one buffer spinlock could be held
>> at a time?

> No. UPDATE holds two spins, btree split even more.
> But stop - afair bufmgr remembers locked buffers, probably
> we could just add XXX_CRIT_SECTION to LockBuffer..?

Right.  A buffer lock isn't a spinlock, ie, we don't hold the spinlock
except within LockBuffer.  So a quick CRIT_SECTION should deal with
that.  Actually, with careful placement of CRIT_SECTION calls in
LockBuffer, there's no need to record holding the buffer's cntxt
spinlock at all, I think.  Will work on it.

			regards, tom lane

Tue, 09 Jan 2001 14:22:32 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Quite strange crash 