On Monday, August 05, 2013 11:57 AM Tom Lane wrote:
> Amit Kapila <amit.kapila@huawei.com> writes:
> > On Saturday, August 03, 2013 12:53 AM Tom Lane wrote:
> >> Yeah, this approach is a nonstarter because there's no reason to
> assume
> >> that a postmaster started with default parameters will start
> >> successfully,
> >> or will be connectable-to if it does start. Maybe there's another
> >> postmaster hogging the default port, for instance.
>
> > Okay, but user will always have option to start server with different
> value
> > of parameter (pg_ctl -o "-p 5434").
>
> You're assuming that the user starts the postmaster manually. On most
> modern installations there's a few layers of scripting in there, which
> might not be that easy to hack to add some command-line parameters,
> even assuming that the DBA has sufficient wits about him to think of
> this solution. (When your postmaster unexpectedly fails to restart
> at four in the morning, having to think of such an approach isn't what
> you want to be doing.)
>
> My point here is just that we should keep the parameter values in plain
> text files,
Here by text files, do you mean to say you are expecting
file-per-guc-setting?
> so that one possible solution is reverting a bogus change
> with
> vi/emacs/your-weapon-of-choice. If we "improve" matters so that the
> only
> possible way to fix the parameter setting is via a running postmaster,
> we've narrowed the number of escape routes that a frantic DBA will
> have.
> And what would we have bought for that? Not much.
Although it is not advisable to edit this file manually, but I think in such
situations (postmaster doesn't start up due to inappropriate parameter
value) it can help user to come out of situation much easily.
My only point was to address the concerns regarding un-safe parameter
values.
With Regards,
Amit Kapila.