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

* Tom Lane (tgl@sss.pgh.pa.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
insome way.  Currently this is done in Ubuntu by having the init script read the directory out of the postgresql.conf,
butit could also be passed through Ubuntu's "pg_ctl.conf", which takes a set of parameters to pass.  I will note here,
thoughit 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
surprisedthat 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
thatfails 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
toohigh, will either cause it to not start or to possible crash very quickly (eg: user set it to however much real
memorythey 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
setthrough ALTER SYSTEM? 

local_preload_libraries- Will start if it's set to something invalid, but then you can't connect because new backend
startswill 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