Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> The latter is a really bad idea IMHO. The io_in_progress lock can be
>> held for eons (in CPU terms) and should not be blocking people who
>> simply want to bump their refcount up and down.
> My reasoning was that t
(Sorry Tom, I was meaning to reply to you once I'd had a chance to
revise the bufmgr patch; since that seems a fair ways off, I figured
it would be better to respond now.)
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> we now hold the buffer's meta data lo
Neil Conway <[EMAIL PROTECTED]> writes:
> - to modify a BufferDesc's meta data (shared refcount, flags, tag,
> etc.), one must hold the buffer's "meta data lock". Also, I
> removed the existing "io_in_progress" lock; instead, we now hold
> the buffer's meta data lock while doi
On Wed, Jan 07, 2004 at 05:37:09PM -0500, Neil Conway wrote:
>
> - if a backend holds the BufMgrLock, it will never try to
> LWLockAcquire() a per-buffer meta data lock, due to the risk of
> deadlock (and the loss in concurrency if we got blocked waiting
> while still holding
I've attached a (gzip'ed) patch that makes the following changes to
the buffer manager:
(1) Overhaul locking; whenever the code needs to modify the state
of an individual buffer, do synchronization via a per-buffer
"meta data lock" rather than the global BufMgrLock. For more
