Re: Sync Rep: First Thoughts on Code

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Sync Rep: First Thoughts on Code
Дата
Msg-id 1229676641.4793.467.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Sync Rep: First Thoughts on Code  ("Fujii Masao" <masao.fujii@gmail.com>)
Ответы Re: Sync Rep: First Thoughts on Code  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Sync Rep: First Thoughts on Code  ("Fujii Masao" <masao.fujii@gmail.com>)
Список pgsql-hackers
On Fri, 2008-12-19 at 09:43 +0900, Fujii Masao wrote:

> > Yes, please check the call points for ForceSyncCommit.
> >
> > Do I think every xlog flush should be synchronous, no, I don't.
> That's why we have a user settable parameter for it.
> 
> Umm.. I focus attention on XLogFlush() called except
> RecordTransactionCommit().
> For example, FlushBuffer(), WriteTruncateXlogRec().. etc. These
> XLogFlush() might
> flush XLOG synchronously even if asynchronous commit case.

XLogFlush() flushes because of an interlock between a dirty buffer write
and an outstanding WAL write. Dirty buffer writes are not replicated, so
there is no need to have a similar interlock on WAL streaming.

So making those call points synchronous is possible, but neither
necessary or IMHO desirable.

On a related but different point: We don't need an interlock between
dirty buffers and WAL during recovery because the WAL has already been
written.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Hot standby and b-tree killed items
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Latest version of Hot Standby patch