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
