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: http://www.postgresql.org/mailpref/pgsql-hackers
