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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting rid of wal_level=archive and default to hot_standby + wal_senders
Date: 2015-02-12 17:48:11
Message-ID: 54DCE75B.8040506@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/3/15 11:00 AM, Robert Haas wrote:
> 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?

We could probably make wal_level changeable at run-time if we somehow
recorded to the point at which it was changed, as you describe later (or
even brute-force it by forcing a checkpoint every time it is changed,
which is not worse than what we require now (or even just write out a
warning that the setting is not effective until after a checkpoint)).

But that still leaves max_wal_senders (and arguably
max_replication_slots) requiring a restart before replication can start.
I don't see a great plan for those on the horizon.

To me, the restart requirement is the killer.

That there are so many interwoven settings isn't great either, but there
will always be more options, and all we can do is manage it.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-02-12 18:00:48 Re: binworld and install-binworld targets - was Re: Release note bloat is getting out of hand
Previous Message Fabrízio de Royes Mello 2015-02-12 17:15:30 Re: Index-only scans for GiST.