Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave |
| Дата | |
| Msg-id | 50F827E6.8050900@vmware.com обсуждение исходный текст |
| Ответ на | Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: Re: Slave enters in recovery and promotes when WAL
stream with master is cut + delay master/slave
|
| Список | pgsql-hackers |
On 17.01.2013 17:42, Andres Freund wrote: > Ok, the attached patch seems to fix a) and b). c) above is bogus, as > explained in a comment in the patch. I also noticed that the TLI check > didn't mark the last source as failed. This looks fragile: > /* > * We only end up here without a message when XLogPageRead() failed > * - in that case we already logged something. > * In StandbyMode that only happens if we have been triggered, so > * we shouldn't loop anymore in that case. > */ > if (errormsg == NULL) > break; I don't like relying on the presence of an error message to control logic like that. Should we throw in an explicit CheckForStandbyTrigger() check in the condition of that loop? - Heikki
В списке pgsql-hackers по дате отправления: