On 2013-08-30 09:43:01 -0400, Stephen Frost wrote:
> * 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.
Yes, we're making progress. But that's an independent thing, partially
constrained by implementation complexity, partially constrained by cross
platform worries.
You're free to work on reducing the dangers around other variables, but
I don't understand in the very least why that should stop this feature.
> I'm not entirely sure how wal_level has the same danger as the
> others..
Try setting max_wal_senders = 10 and wal_level = minimal.
> > > 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'.
Then pg isn't ready already, because it has done that for a long
time. Set some PGC_POSTMASTER variable and reload the configuration.
Guiding a user that to perform required further action doesn't imply
nonreadyness in the least.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
