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 (andres@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.
