| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
| Cc: | Denis Perchine <dyp(at)perchine(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Quite strange crash |
| Date: | 2001-01-09 19:22:32 |
| Message-ID: | 5823.979068152@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-01-09 19:25:42 | Re: Quite strange crash |
| Previous Message | Martin A. Marques | 2001-01-09 19:05:33 | How to print explain using PHP |