Re: log_newpage header comment

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: log_newpage header comment
Дата
Msg-id 2849.1339114004@sss.pgh.pa.us
обсуждение исходный текст
Ответ на log_newpage header comment  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: log_newpage header comment  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It seems that in implementing ginbuildempty(), I falsified the first
> "note" in the header comment for log_newpage():

>  * Note: all current callers build pages in private memory and write them
>  * directly to smgr, rather than using bufmgr.  Therefore there is no need
>  * to pass a buffer ID to XLogInsert, nor to perform MarkBufferDirty within
>  * the critical section.

> 1. Considering that we're logging the entire page, is it necessary (or
> even desirable) to include the buffer ID in the rdata structure?  If
> so, why?  To put that another way, does my abuse of log_newpage
> constitute a bug in gistbuildempty()?

AFAICS, not passing the buffer ID to XLogInsert is not an issue, since
we are logging the whole page in any case.  However, failing to perform
MarkBufferDirty within the critical section definitely is an issue.

> 2. Should we add a new function that does the same thing as
> log_newpage for a shared buffer?  I'm imagining that the signature
> would be:

Either that or rethink building this data in shared buffers.  What's the
point of that, exactly, for a page that we are most certainly not going
to use in normal operation?
        regards, tom lane


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: slow dropping of tables, DropRelFileNodeBuffers, tas
Следующее
От: Sergey Koposov
Дата:
Сообщение: Re: slow dropping of tables, DropRelFileNodeBuffers, tas