Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

From Robert Haas
Subject Re: unite recovery.conf and postgresql.conf
Date
Msg-id CA+TgmoYXE_ELwXRAnDCV+LQmMf2H=ke-uqdxXO8vJOJj+nbCCA@mail.gmail.com
Whole thread Raw
In response to Re: unite recovery.conf and postgresql.conf  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: unite recovery.conf and postgresql.conf
List pgsql-hackers
On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> If you change a parameter that only has effect during recovery then
>>> must get an error if it is changed during normal running.
>>
>> I don't see why.  If you're in normal running and someone changes a
>> parameter that is irrelevant during normal running, that should be a
>> no-op, not an error.
>
> How will it be made into a no-op, except by having a specific flag to
> show that it is irrelevant during normal running?

By default, changing a GUC just updates the value of some global
variable inside every backend.  But unless there's some code that
makes use of that global variable for some purpose, it doesn't have
any practical effect.  Apart from whatever complexities may be imposed
by our choice of implementation, I don't see how this would be any
different from setting maintenance_work_mem in a particular session
and then not running any CREATE INDEX or VACUUM commands in that
session.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
Next
From: Robert Haas
Date:
Subject: Re: IDLE in transaction introspection