Re: Keepalive for max_standby_delay
От | Simon Riggs |
---|---|
Тема | Re: Keepalive for max_standby_delay |
Дата | |
Msg-id | 1274026295.308.10866.camel@ebony обсуждение исходный текст |
Ответ на | Re: Keepalive for max_standby_delay (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Keepalive for max_standby_delay
Re: Keepalive for max_standby_delay |
Список | pgsql-hackers |
On Sat, 2010-05-15 at 19:50 +0100, Simon Riggs wrote: > On Sat, 2010-05-15 at 18:24 +0100, Simon Riggs wrote: > > > I will recode using that concept. > Startup gets new pointer when it runs out of data to replay. That might > or might not include an updated keepalive timestamp, since there's no > exact relationship between chunks sent and chunks received. Startup > might ask for a new chunk when half a chunk has been received, or when > multiple chunks have been received. New version, with some other cleanup of wait processing. New logic is that when Startup asks for next applychunk of WAL it saves the lastChunkTimestamp. That is then the base time used by WaitExceedsMaxStandbyDelay(), except when latestXLogTime is later. Since multiple receivechunks can arrive from primary before Startup asks for next applychunk we use the oldest receivechunk timestamp, not the latest. Doing it this way means the lastChunkTimestamp doesn't change when new keepalives arrive, so we have a stable and reasonably accurate recordSendTimestamp for each WAL record. The keepalive is sent as the first part of a new message, if any. So partial chunks of data always have an accurate timestamp, even if that is slightly older as a result. Doesn't make much difference except with very large chunks. I think that addresses the points raised on this thread and others. -- Simon Riggs www.2ndQuadrant.com
Вложения
В списке pgsql-hackers по дате отправления: