Re: bufmgr code question

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: bufmgr code question
Дата
Msg-id 22884.1067965654@sss.pgh.pa.us
обсуждение исходный текст
Ответ на bufmgr code question  (Neil Conway <neilc@samurai.com>)
Ответы Re: bufmgr code question
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [PATCHES] equal() perf tweak
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Experimental patch for inter-page delay in VACUUM