Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> What if you set a combination of parameters that prevents Postgres from
> starting?

This was what I was trying to get at up-thread. Things that prevent PG
from being able to start (or, really, which cause PG to be started in a
completely different mode, ala recovery.conf) need to be able to be
modified outside of PG and therefore should, imv, be considered
configuration parameters and therefore live outside of $PGDATA (when
installed from a distro, blah, blah).

> We could of course fix that problem by only storing "safe" parameters
> in a catalog, but then you lose the supposed appeal of a single-file
> solution.

I don't see "having them all in one file is more convenient for the
admin" as being a justification for the single-file approach, simply
because I don't consider the 'auto' file to be something that the admin
would be modifying.

Curiously, I've not heard any argument about what parameters are "safe"
and what aren't, though I was asked which ones I thought were safe and
which weren't. Perhaps looking at the specific options that would
likely cause PG to not start would be useful to this discussion.

Off-hand, I see:

data_directory-
Clearly we need to know this before starting, so it has to be defined
somewhere and then passed to PG in some way. Currently this is done
in Ubuntu by having the init script read the directory out of the
postgresql.conf, but it could also be passed through Ubuntu's
"pg_ctl.conf", which takes a set of parameters to pass. I will note
here, though it may apply in other places also, that this part of the
configuration is necessairly the distro's responsibility.

hba_file-
Won't start without one.

ident_file-
We *will* start without one. We'll even start if it's got garbage in
it. I have to admit, I was a bit surprised that this behaves so
differently from hba_file wrt dealing with existance / errors.

listen_addresses-
Won't start if it's invalid, but if it's not there we'll just try to
listen on localhost:5432, but if that fails we won't start.

port-
Similar to listen_addresses

unix_socket_directories, unix_socket_group-
Won't start if it's invalid, will start w/ a default if not set.

ssl_cert_file, ssl_key_file, ssl_ca_file, ssl_crl_file,
krb_server_keyfile, shared_preload_libraries-
Won't start if it's invalid, not used if not set.

shared_buffers-
Older versions won't start if it's set above the SHM limits on the
system. Even in 9.3+ though, if set too high, will either cause it to
not start or to possible crash very quickly (eg: user set it to
however much real memory they have in the system).

log_directory, log_filename-
Won't start if set such that PG can't create the necessary directories
or open its log file.

log_timezone, timezone, lc_messages, lc_monetary, etc-
Won't start if set invalid- can we check validity of this when set
through ALTER SYSTEM?

local_preload_libraries-
Will start if it's set to something invalid, but then you can't
connect because new backend starts will fail.

Now, there's certainly a whole slew of things which *can* be modified
w/o too much risk to being able to get PG started again. Also, many of
the things above could probably be changed to deal with error cases and
keep starting up (eg: ssl_*). Andrew pointed out that we can use
command-line arguments to override badly configured parameters, but I'm
worried that'd simply end up making those items be configured through
the distro scripts, and probably in a way that isn't as nice as
postgresql.conf, eg:

Ubuntu's pg_ctl.conf might become:
pg_ctl_options = '-o "-c listen_addresses=127.0.01.1" -o "-c port=5433"'

etc, or, more likely, a *new* config file being created to manage these
things which is completely distribution-specific...

Thanks,

Stephen