Re: Getting rid of wal_level=archive and default to hot_standby + wal_senders

On Tue, Feb 3, 2015 at 7:43 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> I think these days there's no reason for the split between the archive
> and hot_standby wal levels. The split was made out of volume and
> stability concerns. I think we can by now be confident about the
> wal_level = hot_standby changes (note I'm not proposing hot_standby =
> on).
>
> So let's remove the split. It just gives users choice between two options
> that don't have a meaningful difference.
>
> Additionally I think we should change the default for wal_level to
> hot_standby and max_wal_senders (maybe to 5). That way users can use
> pg_basebackup and setup streaming standbys without having to restart the
> primary. I think that'd be a important step in making setup easier.
>
> Previously there have been arguments against changing the default of
> wal_level because it'd mean the regression tests wouldn't exercise
> minimal anymore. That might be true, but then right now we just don't
> exercise the more complex levels. If we're really concerned we can just
> force a different value during the tests, just as we do for prepared
> xacts.
>
> Comments?
>
> Additionally, more complex and further into the future, I wonder if we
> couldn't also get rid of wal_level = logical by automatically switching
> to it whenever logical slots are active.

I think my vote is to maintain the status quo. What you're basically
proposing to do is ship the system half-configured for replication,
and I don't see the point of that. The people who want replication
still have to do the rest of the setup anyway, and the people who
don't want replication are losing the benefits of wal_level=minimal
for no real gain. In particular, they are losing the ability to skip
WAL-logging when bulk-loading a just-created table, which is not a
small thing. I'm fairly sure we have customers who benefit
significantly from that behavior.

I agree that wal_level=archive doesn't serve much purpose at this
point. I guess I wouldn't object to removing that, although I can't
see much benefit to doing so, either.

Crazy ideas: Could we make wal_level something other than
PGC_POSTMASTER? PGC_SIGHUP would be nice... Could we, maybe, even
make it a derived value rather than one that is explicitly configured?
Like, if you set max_wal_senders>0, you automatically get
wal_level=hot_standby? If you register a logical replication slot,
you automatically get wal_level=logical?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company