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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: "'Stephen Frost'" <sfrost(at)snowman(dot)net>, "'Josh Berkus'" <josh(at)agliodbs(dot)com>, "'Andres Freund'" <andres(at)2ndquadrant(dot)com>, "'Greg Stark'" <stark(at)mit(dot)edu>, "'Alvaro Herrera'" <alvherre(at)2ndquadrant(dot)com>, "'Fujii Masao'" <masao(dot)fujii(at)gmail(dot)com>, "'Robert Haas'" <robertmhaas(at)gmail(dot)com>, "'Dimitri Fontaine'" <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
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: 2013-08-05 06:27:22
Message-ID: 30045.1375684042@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila(at)huawei(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2013-08-05 06:46:18 Re: query_planner() API change
Previous Message Amit Langote 2013-08-05 06:23:19 Bottlenecks with large number of relation segment files