From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TODO questions |
Date: | 2005-08-24 22:53:33 |
Message-ID: | 87d5o3dk0i.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> That all sounds nice, but unless you intend to fix all the constraints
> that force some values to be set-only-at-postmaster-start, it's never
> going to be possible to promise that a reload has the same effect as
> restarting the server. We could do this for values that are not
> PGC_POSTMASTER, but the argument given above for doing it is bogus.
Well that's true, that's a limitation of Postgres's reloading config files.
Certainly I think it should be a goal to avoid any such guc variables where
it's worth the effort. That doesn't mean you have to make the "problem" worse
and go in a completely different direction.
I would say it would be reasonable to print a warning if loading the new
config file results in a different value for any guc variable that can't be
changed.
If that's too awkward then at least it would be nice to put a warning line in
the initial default config file to mark any such guc variables.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-08-25 00:02:59 | Re: [HACKERS] Proposed patch to getaddrinfo.c to support |
Previous Message | Jim C. Nasby | 2005-08-24 22:37:34 | Stuff running slooow |