Re: Standby catch up state change
| От | Pavan Deolasee |
|---|---|
| Тема | Re: Standby catch up state change |
| Дата | |
| Msg-id | CABOikdPAmuYZmJbvQ=H0aEiFAS5rV7ZL1Vx9Pd-aooN4=wWqRw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Standby catch up state change (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: Standby catch up state change
|
| Список | pgsql-hackers |
On Tue, Oct 15, 2013 at 3:59 PM, Andres Freund <andres@2ndquadrant.com> wrote:
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
I don't think that'd be a good idea - the "caughtup" logic is used to
determine whether we need to wait for further wal to be generated
locally if we haven't got anything else to do. And we only need to do so
when we reached the end of the WAL.
Obviously I do not understand the logic caughtup fully, but don't you think the log message about standby having caught up with master while it hasn't because the sender has buffered a lot of data, is wrong ? Or are you saying those are two different things really ?
Also, we'd have to reset caughtup everytime we send data (in
XLogSend()), that'd be horrible.
Sorry, I did not get that. I was only arguing that the log message about standby having caught up with master should be delayed until standby has actually received the WAL, not much about the actual implementation.
Thanks,
Pavan
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
В списке pgsql-hackers по дате отправления: