On Friday, August 02, 2013 4:17 PM Cédric Villemain wrote: Le vendredi 2 août 2013 09:23:17, Amit Kapila a écrit : > On Friday, August 02, 2013 8:57 AM Stephen Frost wrote: > > * Andres Freund (and...@2ndquadrant.com) wrote: >> > > FWIW, I think you've just put the final nail in the coffin of this >> > > patch by raising the barriers unreasonably high. >> > >> > For my 2c, I don't think it's an unreasonable idea to actually >> > *consider* what options are available through this mechanism rather >> > than just presuming that it's a good idea to be able to modify >> > anything, including things that you wouldn't be able to fix after a >> > restart w/o hacking around in $PGDATA. > >> I think if user has set any value wrong such that it doesn't allow server >> to start, >> we can provide an option similar to pg_resetxlog to reset the auto file. > While guessing what changes are safe is hard, it is easy to discover the GUCs preventing PostgreSQL from restarting correctly. > pg_ctl might be able to expose a clear message like : > MSG: Params X and Y set by ALTER SYSTEM prevent PostgreSQL from starting > HINT: Issue pg_ctl --ignore-bad-GUC start > Note that the same may also allow postgresql to start with bad GUC value in postgresql.conf .... > So this is another topic (IMHO).
Yes, this can be viable option to ignore variable values that don't allow server to start, also I agree with you that this can be a separate patch. > With the current idea of one-GUC-one-file in a PGDATA subdirectory it is *easy* to fix for any DBA or admin. > However, note that I do prefer a simple 'include_auto_conf=here|start|end|off' in postgresql.conf (by default at end of file, with value 'end' set). Earlier patch has this implementation, but later based on suggestions, I made it default. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
