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 > 0
wal_level = logical
elif max_wal_senders > 0
wal_level = hot_standby
elif archiving = on
wal_level = archive (or hot_standby)
else
wal_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