From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Plan for resetting commented postgresql.conf vars at sighup |
Date: | 2006-03-07 03:10:25 |
Message-ID: | 12446.1141701025@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com> writes:
> this is the plan: In ParseConfigFile, record the fact that the
> variable was set in response to SIG_HUP in the status field
> (GUC_SET_FROM_SIGHUP). After setting all variables in postgresql.conf,
> set all variables that can appear in postgresql.conf
> (GUC_DISALLOW_IN_FILE), don't have their built-in value still set
> (PGC_S_DEFAULT), may be set from postgresql.conf (context not INTERNAL
> or POSTMASTER) and weren't set from SIGHUP (GUC_SET_FROM_SIGHUP) to
> their built-in default value.
This seems pretty nonrobust, in particular if there's an elog partway
through you will be left with very messed-up state (all the wrong things
will happen next time). Might help to keep the "needs reset" state in
temporary memory instead of the status fields.
> One problem is that set_config_option takes the variable's new value
> as a string,
You should not be thinking in terms of doing this through
set_config_option (its API does not offer any way to reset to default).
So I don't really see the issue here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-03-07 03:12:00 | Re: [HACKERS] Zeroing damaged pages |
Previous Message | Bruce Momjian | 2006-03-07 03:01:43 | Re: pg.conf re-reading in signal handler or at next return |