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

From Tom Lane
Subject Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date
Msg-id 30045.1375684042@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Amit Kapila <amit.kapila@huawei.com>)
Responses Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
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, 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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Bottlenecks with large number of relation segment files
Next
From: Atri Sharma
Date:
Subject: Re: query_planner() API change