Re: Turning recovery.conf into GUCs
От | Andres Freund |
---|---|
Тема | Re: Turning recovery.conf into GUCs |
Дата | |
Msg-id | 20131118172748.GG20305@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Turning recovery.conf into GUCs (Jaime Casanova <jaime@2ndquadrant.com>) |
Ответы |
Re: Turning recovery.conf into GUCs
Re: Turning recovery.conf into GUCs |
Список | pgsql-hackers |
Hi, On 2013-11-15 22:38:05 -0500, Jaime Casanova wrote: > sorry, i clearly misunderstood you. attached a rebased patch with > those functions removed. * --write-standby-enable seems to loose quite some functionality in comparison to --write-recovery-conf since it doesn'tseem to set primary_conninfo, standby anymore. * CheckRecoveryReadyFile() doesn't seem to be a very descriptive function name. * Why does StartupXLOG() now use ArchiveRecoveryRequested && StandbyModeRequested instead of just the former? * I am not sure I like "recovery.trigger" as a name. It seems to close to what I've seen people use to trigger failover andtoo close to trigger_file. * You check for a trigger file in a way that's not compatible with it being NULL. Why did you change that? - if (TriggerFile == NULL) + if (!trigger_file[0]) * You made recovery_target_inclusive/pause_at_recovery_target PGC_SIGHUP - did you review that actually works? Imo that shouldbe changed in a separate commit. * Maybe we should rename names like pause_at_recovery_target to recovery_pause_at_target? Since we already force everyoneto bother changing their setup... * the description of archive_cleanup_command seems wrong to me. * Why did you change some of the recovery gucs to lowercase names, but left out XLogRestoreCommand? * Why the PG_TRY/PG_CATCH in check_recovery_target_time? Besides being really strangely formatted (multiline :? inside afunction?) it doesn't a) seem to be correct to ignore potential memory allocation errors by just switching back into thecontext that just errored out, and continue to work there b) forgo cleanup by just continuing as if nothing happened.That's unlikely to be acceptable. * You access recovery_target_name[0] unconditionally, although it's intialized to NULL. * Generally, ISTM there's too much logic in the assign hooks. * Why do you include xlog_internal.h in guc.c and not xlog.h? Ok, I think that's enough for now ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: