On Tue, Nov 1, 2011 at 2:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> 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
>
> I believe we're logging the fact that we were unable to make the
> change, not the fact that it didn't have any effect. Certainly, it
> *would* have an effect, if we were able to make it. But we can't,
> without a restart, so we tell that to the user.
>
> But, for example, the hot_standby GUC - which already exists - does
> not do anything in normal running. We don't need to (and don't)
> complain if the user tries to change the value in normal running,
> though: they're presumably just hoping it will take effect the next
> time they start up, which it will.
If there is precedence then we should follow it. So no error messages.
The only reason this point has any importance is that Fujii is
suggesting the code will be much more complicated if we retain
recovery.conf compatibility, since we need to mark GUCs with a flag as
to whether they can take effect during recovery. I don't think that's
a lot of work to add, and would make the code clearer than it is now.
> And the autovacuum parameter does
> not do anything during hot standby, but we don't need to (and don't)
> complain if the user changes it them; it just takes effect when we
> enter normal running.
That one needs to be set on a standby, in case it becomes a primary.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
