Defaults for GUC variables (was Re: pg_ctl reports succes when start fails)
От | Tom Lane |
---|---|
Тема | Defaults for GUC variables (was Re: pg_ctl reports succes when start fails) |
Дата | |
Msg-id | 29413.1067268152@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_ctl reports succes when start fails (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
Ответы |
Re: Defaults for GUC variables (was Re: pg_ctl reports
Re: Defaults for GUC variables (was Re: pg_ctl reports Re: Defaults for GUC variables (was Re: pg_ctl reports succes when start fails) |
Список | pgsql-hackers |
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: >>> The latter...why won't it affect the postmaster state? >> >> Because it's a *comment*. > Shouldn't it revert to the default value? No, not unless you think the postmaster should react to comments in the postgresql.conf file, which is rather against my idea of a comment. However, you're not the first to get burnt by this mis-assumption, so maybe we should do something about it. The low-tech solution to this would be to stop listing the default values as commented-out entries, but just make them ordinary uncommented entries. That way people who think "undoing my edit will revert the change" would be right. Or we could try to make it actually work the way you seem to be expecting. The only implementation I can think of is to reset GUC variables to defaults just before scanning the .conf file (but only if their prior value came from the .conf file, which fortunately is something we keep track of). The trouble with this is that any error in scanning the .conf file could leave you with unexpectedly reverted values for later entries, because they'd not be reached. Or we could just document the behavior better... regards, tom lane
В списке pgsql-hackers по дате отправления: