Re: Sync Rep: First Thoughts on Code
От | Aidan Van Dyk |
---|---|
Тема | Re: Sync Rep: First Thoughts on Code |
Дата | |
Msg-id | 20081211151509.GZ26596@yugib.highrise.ca обсуждение исходный текст |
Ответ на | Re: Sync Rep: First Thoughts on Code (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Sync Rep: First Thoughts on Code
|
Список | pgsql-hackers |
* Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> [081211 10:09]: > Simon Riggs wrote: >> On Thu, 2008-12-11 at 09:27 -0500, Aidan Van Dyk wrote: >> >>> But "catchup" *has* to be *done* before PostgreSQL can enter "sync rep". >> >> Not true. Please reread the thread where Heikki questions that and I >> reply. This was Fujii-san's idea, which I now agree with. > > I think the confusion here is about what exactly "sync rep" means in > this situation. It's true that you can start streaming the WAL before > the standby has fully caught up. But from the client's point of view, > there's not much point in streaming the log *synchronously* and making > the client to wait for the acknowledment from the standby, if the > acknowledgment from the standby that WAL has be streamed up to point X, > doesn't actually guarantee that the slave can recover all the way to > that point. Quite possibly a terminology problem.. I my case I said "sync rep" meaning the mode such that the transaction doesn't commit successfully for my PG client until the xlog record has been "streamed" to the client... and I understand that at his presentation at PGcon, Fujii-san there could be possible variants on when the "streamed" is considered done based on network, slave ram, disk, application, etc. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: