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 14:04:43 |
Message-ID: | CA+TgmoZZdeVnJrE0k-LcEUMJsoBTebkdmM9C+4kJmyidefhF9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs <simon(at)2ndquadrant(dot)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. 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.
The only time I think we need to complain about an effort to change a
GUC is when the GUC won't take effect as soon as the user might
normally expect.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-11-01 14:06:23 | Re: IDLE in transaction introspection |
Previous Message | Simon Riggs | 2011-11-01 14:04:06 | Re: IDLE in transaction introspection |