From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bufmgr code question |
Date: | 2003-11-12 03:03:08 |
Message-ID: | 200311120303.hAC338d29356@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Is there a TODO here?
---------------------------------------------------------------------------
Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-11-12 03:04:05 | Re: equal() perf tweak |
Previous Message | Marc G. Fournier | 2003-11-12 01:33:39 | Re: About the partial tarballs |