Re: Plan for resetting commented postgresql.conf vars at sighup

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

In response to

Browse pgsql-hackers by date

  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