Re: bufmgr code question - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: bufmgr code question
Date
Msg-id 200311120303.hAC338d29356@candle.pha.pa.us
Whole thread Raw
In response to Re: bufmgr code question  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: bufmgr code question  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Is there a TODO here?

---------------------------------------------------------------------------

Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
> > In the BufferDesc struct, there seem to be two ways to mark a buffer
> > page as dirty: setting the BM_DIRTY bit mask in the 'flags' field of the
> > struct, and setting the 'cntxDirty' field to true. What is the
> > difference between these two indications of a page's dirtiness?
> > Or, more to the point, is there a reason we have two ways to do what
> > looks like the same thing?
> 
> I believe the reason for this is that you are allowed to set cntxDirty
> to TRUE while holding (only) the context lock on the buffer, while
> messing with the buffer flags word requires holding (only) the
> BufMgrLock.  Getting rid of cntxDirty would mean additional grabbings of
> the BufMgrLock when we want to mark buffers dirty.
> 
> The real solution to this is probably to rethink the rules for locking
> in the buffer manager.  I've thought for some time that the BufMgrLock is
> a system-wide bottleneck; if we could replace it by finer-grain locks,
> and in particular use the per-buffer locks for operations affecting just
> the state of a single buffer, we'd be ahead of the game.
> 
> > BTW, I'd like to remove the behavior that LockBuffer(buf, EXCLUSIVE)
> > automatically marks the page as dirty.
> 
> Yeah.  This has been discussed before, see the archives:
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00488.php
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00679.php
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00512.php
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: About the partial tarballs
Next
From: Bruce Momjian
Date:
Subject: Re: Darwin Startup Script Patch