From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
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-04 19:13:11 |
Message-ID: | 54D26F47.2050403@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2015-02-04 19:24:14 | binworld and install-binworld targets - was Re: Release note bloat is getting out of hand |
Previous Message | Josh Berkus | 2015-02-04 18:05:00 | Re: Redesigning checkpoint_segments |