On Tue, Nov 1, 2011 at 1:23 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs <si...@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.

Why do we have this log message then, if it is OK to ignore changes
that have no effect?

LOG:  parameter "shared_buffers" cannot be changed without restarting the server

 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to