Re: could recovery_target_timeline=latest be the default in standbymode?
От | Michael Paquier |
---|---|
Тема | Re: could recovery_target_timeline=latest be the default in standbymode? |
Дата | |
Msg-id | 20190108033750.GJ22498@paquier.xyz обсуждение исходный текст |
Ответ на | Re: could recovery_target_timeline=latest be the default in standbymode? (David Steele <david@pgmasters.net>) |
Ответы |
Re: could recovery_target_timeline=latest be the default in standbymode?
Re: could recovery_target_timeline=latest be the default in standbymode? |
Список | pgsql-hackers |
On Mon, Dec 31, 2018 at 01:21:00PM +0200, David Steele wrote: > This patch looks good to me. (Sorry for the delay here) 0001 looks fine to me. - to the latest timeline found in the archive, which is useful in - a standby server. Other than that you only need to set this parameter + to the latest timeline found in the archive. That is the default. + </para> Isn't it useful to still mention that the default is useful especially for standby servers? - the WAL archive. If you plan to have multiple standby servers for high - availability purposes, set <varname>recovery_target_timeline</varname> to - <literal>latest</literal>, to make the standby server follow the timeline change - that occurs at failover to another standby. + the WAL archive. I think that we should still keep this recommendation as well, as well as the one below. - RecoveryTargetTimeLineGoal rttg = RECOVERY_TARGET_TIMELINE_CONTROLFILE; + RecoveryTargetTimeLineGoal rttg; Good to remove this noise. > Yes, that's exactly what I was thinking. Agreed. > There don't seem to be any tests for recovery_target_timeline=current. This > is an preexisting condition but it probably wouldn't hurt to add one. Yes, I got to wonder while looking at this patch why we don't have one yet in 003_recovery_targets.pl. That's easy enough to do thanks to the extra rows inserted after doing the stuff for the LSN-based restart point, and attached is a patch to add the test. Peter, could you merge it with 0001? I am fine to take care of that myself if necessary. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: