From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unite recovery.conf and postgresql.conf |
Date: | 2011-11-01 13:23:36 |
Message-ID: | CA+TgmoYXE_ELwXRAnDCV+LQmMf2H=ke-uqdxXO8vJOJj+nbCCA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-11-01 13:38:16 | Re: IDLE in transaction introspection |
Previous Message | Merlin Moncure | 2011-11-01 13:16:23 | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? |