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 по дате отправления: