Re: Proposal for 9.1: WAL streaming from WAL buffers

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: Proposal for 9.1: WAL streaming from WAL buffers
Дата
Msg-id 3A3E45C4-3078-45B2-8AE7-9C4758E8F7F8@phlo.org
обсуждение исходный текст
Ответ на Re: Proposal for 9.1: WAL streaming from WAL buffers  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Jun 15, 2010, at 10:45 , Fujii Masao wrote:
> A transaction commit would need to wait for local fsync and replication
> in a serial manner, in synchronous replication. IOW, walsender cannot
> send the commit record until it's fsync'd in XLogWrite().

Hm, but since 9.0 won't do synchronous replication anyway, the right thing to do for 9.0 is still to send only fsync'ed
WAL,no? Without synchronous replication the overhead seems negligible. 

For synchronous replication (and hence for 9.1) I think there are two basic options

a) Stream only fsync'ed WAL, like in the asynchronous case. Depending on policy, additionally wait for one or more
slavesto fsync before reporting success. 

b) Stream non-fsync'ed WAL. on COMMIT, wait for at last one node (not necessarily the master, exact count depends on
policy)to fsync before reporting success. During recovery of the master, recover up to the latest LSN found on any one
ofthe nodes. 

Option (b) requires some additional thought, though. Controlled removal of slave nodes and concurrent crashes of more
thanone node are the most difficult areas to handle gracefully, it seems. 

best regards,
Florian Pflug



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal for 9.1: WAL streaming from WAL buffers
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: [BUGS] Server crash while trying to read expression using pg_get_expr()