Re: hot_standby_feedback doesn't work on busy servers in 9.3+
От | Heikki Linnakangas |
---|---|
Тема | Re: hot_standby_feedback doesn't work on busy servers in 9.3+ |
Дата | |
Msg-id | 52D84DFD.3040503@vmware.com обсуждение исходный текст |
Ответ на | Re: hot_standby_feedback doesn't work on busy servers in 9.3+ (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: hot_standby_feedback doesn't work on busy servers in 9.3+
|
Список | pgsql-bugs |
On 01/16/2014 10:44 AM, Andres Freund wrote: > On 2014-01-16 10:26:51 +0530, Amit Kapila wrote: >>> Looking into this I also noticed that the busy path is odd, because a) >>> why are we sending a reply before flushing things to disk? b) >>> XLogWalRcvFlush() will do it's own XLogWalRcvSendReply(). >> >> I think call to reply in XLogWalRcvFlush() might not actually send >> reply because of time difference of last Reply message which we >> sent before flush call. > > Yes, but most of the time that will lead to only outdated data to be > sent since that's the first call. Hardly a severe issue, odd nonetheless. > >> The only point that occurs to me for having such a code is that >> incase flush call fails due to disk space or some other such issue, >> it can atleast send the correct write position to primary. > > Unconvinced. The reply message contains a pointers for how far the WAL has been applied, written, and flushed. There can be a significant delay between the write and flush steps, so we send a separate reply after writing, and after flushing. (if we didn't, the flush and write pointers sent to the master would always be the equal). - Heikki
В списке pgsql-bugs по дате отправления: