Re: RFC: bufmgr locking changes

From: Kurt Roeckx <Q(at)ping(dot)be>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: bufmgr locking changes
Date: 2004-01-08 01:05:18
Message-ID: 20040108010518.GA26041@ping.be
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 the BufMgrLock). Instead it does a
> LWLockConditionalAcquire() and handles an acquisition failure
> sanely

I can only see this work when you always check that you actually
got the right buffer after you locked the meta data. There is
nothing preventing an other backend from using it to for
something else in it between the time you release the BufMgrLock
and you lock the buffer's meta data.

Note that your PinBuffer() is now always called when you already
have the lock meta lock, which is probably a good idea or you're
going to make that function more complex that it should be. Just
say that it should hold the meta lock instead of the BufMgrLock
when it's called.

Kurt

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-01-08 01:20:02 Re: [COMMITTERS] pgsql-server/ oc/src/sgml/catalogs.sgml
Previous Message Neil Conway 2004-01-07 22:37:09 RFC: bufmgr locking changes