log_newpage header comment

Поиск
Список
Период
Сортировка
От Robert Haas
Тема log_newpage header comment
Дата
Msg-id CA+Tgmob2XEN5xJw651uLQDWR5Va59N=KKWKJx1_HttbyoTYp2Q@mail.gmail.com
обсуждение исходный текст
Ответы Re: log_newpage header comment  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.
Thereforethere is no need* to pass a buffer ID to XLogInsert, nor to perform MarkBufferDirty within* the critical
section.

Mea culpa, mea culpa, mea maxima culpa.

So, this leads to a couple of questions:

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()?

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:

XLogRecPtr log_newpage_buffer(RelFileNode *rnode, Buffer buffer);

Admittedly, it may seem that we don't quite need such a function to
cater to just one caller, but I think we might have more in the
future.  Among other things, it occurs to me to wonder whether I ought
to rewrite all the ambuildempty routines in the style of
ginbuildempty(), to avoid having to fsync in the foreground.  Even if
not, I think there might be other applications for this.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: New Postgres committer: Kevin Grittner
Следующее
От: Robert Haas
Дата:
Сообщение: Re: New Postgres committer: Kevin Grittner