On Fri, Aug 30, 2013 at 9:19 AM, Stephen Frost <sfrost@snowman.net> wrote:
> You and Robert both seem to be of the opinion that this hack which
> brings postgresql.conf into the database via ALTER SYSTEM is a-ok
> because it's moving us "forward" in someone's mind, but it really is
> developing a system configuration management system which *looks* like a
> first-class citizen when it actually falls woefully short of that.
It's not a system configuration management system, and it doesn't
pretend to be. It's an analogue of ALTER USER and ALTER DATABASE that
papers over their shortcomings, and a safer alternative to adminpack's
kludgy way of enabling the same functionality.
> There is absolutely no question in my mind that this will be a huge
> support pain, from the first "ALTER SYSTEM SET shared_buffers = blah;
> SHOW shared_buffers;"
They'd have the same problem with ALTER USER SET work_mem = blah.
You're acting like ALTER commands that don't take immediate effect are
something brand-new, but we've had them for years.
> to the "why can't my database start?!? it's
> complaining it can't allocate memory but I keep changing postgresql.conf
> and nothing works!"
As of 9.3, that failure mode doesn't really happen any more, unless
you maybe set shared_buffers equal to 100% of system memory.
> I'm simply not convinced that this is moving us
> forward nor that we will end up with more benefit than pain from it.
Fair enough, but I'm not convinced that we'll derive any pain at all
from it. The existing similar features haven't been a notable source
of complaints AFAIK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
