* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
> > wal_level and shared_buffers I can buy, but listen_addresses? The most
> > typical change there is going from localhost -> '*', but you've got to
> > be on the box to do that. Anything else and you're going to need to be
> > adding interfaces to the box anyway and hacking around in
> > /etc/network/interfaces or what-have-you.
>
> Even if it requires to be on the box locally, I only need libpq for
> it. And it's not infrequent to allow additional, already configured
> interfaces. And even if not, what's the point of prohibiting
> listen_interfaces specifically? When the other very interesting
> variables have the same dangers?
I'd like to see those dangers removed from the other very interesting
variables. We're making progress towards that, for example with
shared_buffers. I've commented on that already up-thread. Hell, you
could even make things such that PG would start w/ a misconfigured
listen_addresses- but if we don't like that then I would argue that it
shouldn't be included here. I'm not entirely sure how wal_level has the
same danger as the others..
> Doing this on a variable-by-variable basis will a) be a ridiculous
> amount of effort, b) confuse users which may not share our judgement of
> individual variables.
I don't think the effort involved is nearly as much as you claim and we
already have the issue that users don't like our choices around what can
be reconfigured on the fly and what can't (perhaps they understand that
there are technical challenges to some of them, but that doesn't make
them agree with them).
> > 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 what plenty of people want and it doesn't hurt people who do not
> want it. Yes. I think that's a step forward.
It will be quite interesting to see if people decide they really wanted
this once they actually *get* it.
> > 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;" 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!" I'm simply not convinced that this is moving us
> > forward nor that we will end up with more benefit than pain from it.
>
> That will not show the changed shared_buffers. And it (afair) will throw
> a WARNING that shared_buffers couldn't be adjusted at this point.
Not showing the change is what I was getting at. As has been said
elsewhere, throwing a warning on every interesting invokation of a
command can speak to it not being exactly 'ready'.
Thanks,
Stephen
