Tom Lane wrote:
>
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > Tom Lane wrote:
> >> On second thought, that just moves the race condition upstream (to the
> >> person editing postgresql.conf) ... so never mind that idea.
>
> > I didn't actually look at that part of the code yet ... why would any
> > backend read postgresql.conf?
>
> At SIGHUP, the postmaster re-reads postgresql.conf, and each backend
> must do so too --- there's no other way for pre-existing backends to
> learn about changed values. The assumption is that this happens over a
> short enough timespan that it's okay from the perspective of the person
> editing postgresql.conf. But if newly started backends were to read
> postgresql.conf when they start, that would be bad news for someone
> trying to edit postgresql.conf, because there'd be no way to know when
> it would happen.
Sure is there ... the way I did it originally.
The postmaster reads the config file and overrides with commandline
options. Then he dumps ALL options into a separate file.
A backend does not need to read the config file or parse commandline at
all. It just jeads the postmaster provided file.
If the user changes the config and HUP's the postmaster, postmaster
rereads the config and merges only those changes, that are changable at
runtime into it's status. From that status it creates the new file,
renames, HUP's the backends and they reread that file.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #