Re: Turning recovery.conf into GUCs
От | Petr Jelinek |
---|---|
Тема | Re: Turning recovery.conf into GUCs |
Дата | |
Msg-id | 54AAF093.7090402@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Turning recovery.conf into GUCs (Alex Shulgin <ash@commandprompt.com>) |
Список | pgsql-hackers |
On 24/12/14 20:11, Alex Shulgin wrote: > Alex Shulgin <ash@commandprompt.com> writes: > >>> - the StandbyModeRequested and StandbyMode should be lowercased like >>> the rest of the GUCs >> >> Yes, except that standby_mode is linked to StandbyModeRequested, not the >> other one. I can try see if there's a sane way out of this. > > As I see it, renaming these will only add noise to this patch, and there > is also ArchiveRecoveryRequested / InArchiveRecovery. This is going to > be tricky and I'm not sure it's really worth the effort. > I don't buy that to be honest, most (if not all) places that would be affected are already in diff as part of context around other renames anyway and it just does not seem right to rename some variables and not the others. I still think there should be some thought given to merging the hot_standby and standby_mode, but I think we'd need opinion of more people (especially some committers) on this one. >>> - The whole CopyErrorData and memory context logic is not needed in >>> check_recovery_target_time() as the FlushErrorState() is not called >>> there >> >> You must be right. I recall having some trouble with strings being >> free'd prematurely, but if it's ERROR, then there should be no need for >> that. I'll check again. > > Hrm, after going through this again I'm pretty sure that was correct: > the only way to obtain the current error message is to use > CopyErrorData(), but that requires you to switch back to non-error > memory context (via Assert). Right, my bad. > > The FlushErrorState() call is not there because it's handled by the hook > caller (or it can exit via ereport() with elevel==ERROR). > Yes I've seen that, shouldn't you FreeErrorData(edata) then though? I guess it does not matter too much considering that you are going to throw error and die eventually anyway once you are in that code path, maybe just for the clarity... -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: