Re: Keepalive for max_standby_delay
От | Simon Riggs |
---|---|
Тема | Re: Keepalive for max_standby_delay |
Дата | |
Msg-id | 1274981186.4405.100.camel@ebony обсуждение исходный текст |
Ответ на | Re: Keepalive for max_standby_delay (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Keepalive for max_standby_delay
Re: Keepalive for max_standby_delay Re: Keepalive for max_standby_delay |
Список | pgsql-hackers |
On Wed, 2010-05-26 at 16:22 -0700, Josh Berkus wrote: > > Just this second posted about that, as it turns out. > > > > I have a v3 *almost* ready of the keepalive patch. It still makes sense > > to me after a few days reflection, so is worth discussion and review. In > > or out, I want this settled within a week. Definitely need some R&R > > here. > > Does the keepalive fix all the issues with max_standby_delay? Tom? OK, here's v4. Summary * WALSender adds a timestamp onto the header of every WAL chunk sent. * Each WAL record now has a conceptual "send timestamp" that remains constant while that record is replayed. This is used as the basis from which max_standby_delay is calculated when required during replay. * Send timestamp is calculated as the later of the timestamp of chunk in which WAL record was sent and the latest XLog time. * WALSender sends an empty message as a keepalive when nothing else to send. (No longer a special message type for the keepalive). I think its close, but if there's a gaping hole here somewhere then I'll punt for this release. -- Simon Riggs www.2ndQuadrant.com
Вложения
В списке pgsql-hackers по дате отправления: