Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Date
Msg-id 1272536392.4161.13166.camel@ebony
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Thu, 2010-04-29 at 12:55 +0300, Heikki Linnakangas wrote:

> Seems overly complicated. 

If you turn wal_level = hot_standby in the master, then the slaves work,
unless you say otherwise. What is complicated about that?

> It would be simpler to just set it 'off' by
> default.

As a parameter, yes, it is simpler. 
The behaviour is not simplified by doing that.

I care about the behaviour.

> If it's 'off' by default, and you want to use hot standby, you will
> notice quickly that the server doesn't accept connections, and you
> switch it on. If it's 'on' (or 'auto'), you might not realize that your
> standby server is accepting connections, when you only wanted to set it
> up as a warm standby server for high availability.

That requires we hit the problem, alter the parameter and restart. We
don't need to do that at all. It could "Just Work".

> The 'auto' mode just makes it more surprising. Connections might be
> allowed at first, but when someone switches wal_level in the primary for
> some reason, your reporting standby is up, but no longer allows
> connections.

If you don't do this, what would happen on standby? Does it silently
stop applying changes after the point you turned it off, or does it
throw an ERROR.

> And vice versa, if you set up a warm standby server for
> high availability where you don't want to allow connections, and someone
> flips the wal_level switch in the master, the standby suddenly starts
> accepting connections.

Some people would regard that as a good thing. The whole point of
wal_level discussion was to avoid needing multiple switches to turn
something on. You are proposing exactly that here. Why is this
discussion different? Why should we not be able to set in just one
place.

If that behaviour concerns the DBA then they can turn it off explicitly.

> I can't imagine a situation where "allow connections if the WAL allows
> it" would be a sensible setting. If there is one, we could have an
> 'auto' mode, but not as the default.

I can. Simple, obvious behaviour. Turn it on in the master, works on the
standbys. We want people to use the feature, not fumble with it.

Just think "auto" means "linked to master". If you don't like it you can
turn it off.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Cédric Villemain
Date:
Subject: Re: Choosing between seqscan and bitmap scan
Next
From: Heikki Linnakangas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct