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

On 02/04/2015 06:48 AM, Robert Haas wrote:
> Anyway, I'm not talking about deriving the GUC, I'm talking about
> deriving the WAL level which is currently controlled solely by the
> GUC.  We do something like this for full-page writes.  Even if you in
> general have full_page_writes=off, trying to take a hot backup forces
> it on.  This is smart.  I think we could do something similar for
> replication & hot backup.  Suppose we remove the wal_level GUC
> altogether, but there's a control file property that indicates whether
> replication (broadly construed to include hot backup and PITR) is
> enabled.  Actually, more specifically, we store an LSN.  If it's 0,
> replication features are disabled; if it's the location of the
> previous checkpoint, we're in the process of enabling replication
> features; if it precedes the location of the previous checkpoint,
> replication features are enabled.
> 
> Then, we add a command like this:
> 
> ALTER SYSTEM REPLICATION ENABLE;
> 
> When you do that, it sets the LSN in the control file to the location
> of the most recent checkpoint, and then triggers a checkpoint.  When
> the checkpoint is complete, it returns.  You can shut it off again by
> saying:
> 
> ALTER SYSTEM REPLICATION DISABLE;

This would be awesome, and a huge step forward in usability.

Question, though: do we want to distinguish between "hot_standby" and
"logical" levels?  Does this depend on anything other than the WAL log
volume/speed?  If not, we can do some tests.

If Robert's suggestion proves prohibitively difficult, I also +1 the
idea of not having a user-visible wal_level setting at all.
Specifically, I'd love the following behavior:

if logical_replication_slots > 0wal_level = logical
elif max_wal_senders > 0wal_level = hot_standby
elif archiving = onwal_level = archive (or hot_standby)
elsewal_level = minimal

Given that this decision tree is the only possible decision tree, it
makes you kind of wonder why we have an explicit GUC in the first place.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com