remove wal_level archive
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0]/messages/by-id/20150203124317.GA24767@awork2.anarazel.de[1]/messages/by-id/55D31E0D.8060801@gmx.net
Let's get something going. While we have not reached a complete
consensus yet, a few things have become clear:
- We would like to have fewer or easier to change settings.
- It looks like some folks would prefer a switchover to a completely new
and better system, but my experience in these kinds of matters is that
it's better to take smaller steps or we won't get anything changed.
- The distinction between wal_level settings "archive" and "hot_standby"
is in the way of automation or better intelligence, because the primary
cannot tell what the receiver intends to do with the WAL.
So here is a patch to get rid of the distinction.
Bike-shedding: In this patch, I removed "archive" and kept
"hot_standby", because that's what the previous discussions suggested.
Historically and semantically, it would be more correct the other way
around. On the other hand, keeping "hot_standby" would probably require
fewer configuration files to be changed. Or we could keep both, but
that would be confusing (for users and in the code).
I kept the distinction between XLogIsNeeded() and
XLogStandbyInfoActive(), because it is kind of nice for documentation
(although the names are terrible).
The changed comment in xlog_redo() could probably use some review or a
bit more detailed reasoning.
There were a couple of places that I felt were overly coupled with the
wal_level settings. The XLogArchiving*() macros shouldn't really care
what wal_level is, because that is checked elsewhere. I replaced that
with assertions. The check in CheckSlotRequirements() seems
unnecessary. Why can I not add and remove slots while wal_level is minimal?
The documentation and error messages could also use more overhaul. Some
parts say things like "archive or higher", implying that the user knows
about the ordering, other parts list all the allowed options, possibly
implying that they are mutually exclusive variants.
Maybe some of these things could be split out into separate patches.
[0]: /messages/by-id/20150203124317.GA24767@awork2.anarazel.de
/messages/by-id/20150203124317.GA24767@awork2.anarazel.de
[1]: /messages/by-id/55D31E0D.8060801@gmx.net
Attachments:
0001-Remove-wal_level-archive-fold-into-hot_standby.patchtext/x-patch; name=0001-Remove-wal_level-archive-fold-into-hot_standby.patchDownload
>From 612dee3ccb5b49f21c2195c5b9d13fc87d1f9d58 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 31 Aug 2015 22:36:08 -0400
Subject: [PATCH] Remove wal_level "archive", fold into "hot_standby"
This distinction exists only because at the time "hot_standby" was
added, there was some uncertainty about stability. This is now a long
time ago. We would like to move forward with simplifying the
replication configuration, but this distinction is in the way, because a
primary server cannot tell (without asking a standby or predicting the
future) which one of these would be the appropriate level.
---
doc/src/sgml/backup.sgml | 2 +-
doc/src/sgml/config.sgml | 19 ++++---------------
src/backend/access/rmgrdesc/xlogdesc.c | 1 -
src/backend/access/transam/xlog.c | 12 +++++-------
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/postmaster.c | 2 +-
src/backend/replication/slot.c | 5 -----
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 2 +-
src/bin/pg_controldata/pg_controldata.c | 2 --
src/include/access/xlog.h | 7 +++----
11 files changed, 17 insertions(+), 39 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 75dabe9..7f52232 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1285,7 +1285,7 @@ <title>Standalone Hot Backups</title>
If more flexibility in copying the backup files is needed, a lower
level process can be used for standalone hot backups as well.
To prepare for low level standalone hot backups, set <varname>wal_level</> to
- <literal>archive</> or higher, <varname>archive_mode</> to
+ <literal>hot_standby</> or higher, <varname>archive_mode</> to
<literal>on</>, and set up an <varname>archive_command</> that performs
archiving only when a <emphasis>switch file</> exists. For example:
<programlisting>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e3dc23b..ad30a9e 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1952,8 +1952,8 @@ <title>Settings</title>
<varname>wal_level</> determines how much information is written
to the WAL. The default value is <literal>minimal</>, which writes
only the information needed to recover from a crash or immediate
- shutdown. <literal>archive</> adds logging required for WAL archiving;
- <literal>hot_standby</> further adds information required to run
+ shutdown. <literal>hot_standby</> adds logging required for WAL
+ archiving as well as information required to run
read-only queries on a standby server; and, finally
<literal>logical</> adds information necessary to support logical
decoding. Each level includes the information logged at all lower
@@ -1972,22 +1972,11 @@ <title>Settings</title>
transaction</member>
</simplelist>
But minimal WAL does not contain enough information to reconstruct the
- data from a base backup and the WAL logs, so <literal>archive</> or
+ data from a base backup and the WAL logs, so <literal>hot_standby</> or
higher must be used to enable WAL archiving
(<xref linkend="guc-archive-mode">) and streaming replication.
</para>
<para>
- In <literal>hot_standby</> level, the same information is logged as
- with <literal>archive</>, plus information needed to reconstruct
- the status of running transactions from the WAL. To enable read-only
- queries on a standby server, <varname>wal_level</> must be set to
- <literal>hot_standby</> or higher on the primary, and
- <xref linkend="guc-hot-standby"> must be enabled in the standby. It is
- thought that there is little measurable difference in performance
- between using <literal>hot_standby</> and <literal>archive</> levels,
- so feedback is welcome if any production impacts are noticeable.
- </para>
- <para>
In <literal>logical</> level, the same information is logged as
with <literal>hot_standby</>, plus information needed to allow
extracting logical changesets from the WAL. Using a level of
@@ -2655,7 +2644,7 @@ <title>Sending Server(s)</title>
higher than the maximum number of expected clients so disconnected
clients can immediately reconnect. This parameter can only
be set at server start. <varname>wal_level</> must be set to
- <literal>archive</> or higher to allow connections from standby
+ <literal>hot_standby</> or higher to allow connections from standby
servers.
</para>
</listitem>
diff --git a/src/backend/access/rmgrdesc/xlogdesc.c b/src/backend/access/rmgrdesc/xlogdesc.c
index 4f29136..035cefd 100644
--- a/src/backend/access/rmgrdesc/xlogdesc.c
+++ b/src/backend/access/rmgrdesc/xlogdesc.c
@@ -25,7 +25,6 @@
*/
const struct config_enum_entry wal_level_options[] = {
{"minimal", WAL_LEVEL_MINIMAL, false},
- {"archive", WAL_LEVEL_ARCHIVE, false},
{"hot_standby", WAL_LEVEL_HOT_STANDBY, false},
{"logical", WAL_LEVEL_LOGICAL, false},
{NULL, 0, false}
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 68e33eb..14e63fe 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5847,7 +5847,7 @@ static void
CheckRequiredParameterValues(void)
{
/*
- * For archive recovery, the WAL must be generated with at least 'archive'
+ * For archive recovery, the WAL must be generated with at least 'hot_standby'
* wal_level.
*/
if (ArchiveRecoveryRequested && ControlFile->wal_level == WAL_LEVEL_MINIMAL)
@@ -9480,10 +9480,8 @@ xlog_redo(XLogReaderState *record)
/*
* Update minRecoveryPoint to ensure that if recovery is aborted, we
* recover back up to this point before allowing hot standby again.
- * This is particularly important if wal_level was set to 'archive'
- * before, and is now 'hot_standby', to ensure you don't run queries
- * against the WAL preceding the wal_level change. Same applies to
- * decreasing max_* settings.
+ * This is important if the max_* settings are decreased, to ensure
+ * you don't run queries against the WAL preceding the change.
*/
minRecoveryPoint = ControlFile->minRecoveryPoint;
minRecoveryPointTLI = ControlFile->minRecoveryPointTLI;
@@ -9830,7 +9828,7 @@ do_pg_start_backup(const char *backupidstr, bool fast, TimeLineID *starttli_p,
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for making an online backup"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"hot_standby\" or \"logical\" at server start.")));
if (strlen(backupidstr) > MAXPGPATH)
ereport(ERROR,
@@ -10301,7 +10299,7 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for making an online backup"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"hot_standby\" or \"logical\" at server start.")));
/*
* OK to update backup counters and forcePageWrites
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 329bb8c..e29726c 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -154,7 +154,7 @@ pg_create_restore_point(PG_FUNCTION_ARGS)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for creating a restore point"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"hot_standby\" or \"logical\" at server start.")));
restore_name_str = text_to_cstring(restore_name);
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 000524d..9b6aa45 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -855,7 +855,7 @@ PostmasterMain(int argc, char *argv[])
(errmsg("WAL archival cannot be enabled when wal_level is \"minimal\"")));
if (max_wal_senders > 0 && wal_level == WAL_LEVEL_MINIMAL)
ereport(ERROR,
- (errmsg("WAL streaming (max_wal_senders > 0) requires wal_level \"archive\", \"hot_standby\", or \"logical\"")));
+ (errmsg("WAL streaming (max_wal_senders > 0) requires wal_level \"hot_standby\" or \"logical\"")));
/*
* Other one-time internal sanity checks can go here, if they are fast.
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index c66619c..1383339 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -775,11 +775,6 @@ CheckSlotRequirements(void)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
(errmsg("replication slots can only be used if max_replication_slots > 0"))));
-
- if (wal_level < WAL_LEVEL_ARCHIVE)
- ereport(ERROR,
- (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("replication slots can only be used if wal_level >= archive")));
}
/*
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 695a88f..2c32bfb 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -172,7 +172,7 @@
# - Settings -
-#wal_level = minimal # minimal, archive, hot_standby, or logical
+#wal_level = minimal # minimal, hot_standby, or logical
# (change requires restart)
#fsync = on # turns forced synchronization on or off
#synchronous_commit = on # synchronization level;
diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
index dc96bbf..35472a3 100644
--- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
@@ -36,7 +36,7 @@
open CONF, ">>$tempdir/pgdata/postgresql.conf";
print CONF "max_replication_slots = 10\n";
print CONF "max_wal_senders = 10\n";
-print CONF "wal_level = archive\n";
+print CONF "wal_level = hot_standby\n";
close CONF;
restart_test_server;
diff --git a/src/bin/pg_controldata/pg_controldata.c b/src/bin/pg_controldata/pg_controldata.c
index 046480c..8368d8e 100644
--- a/src/bin/pg_controldata/pg_controldata.c
+++ b/src/bin/pg_controldata/pg_controldata.c
@@ -74,8 +74,6 @@ wal_level_str(WalLevel wal_level)
{
case WAL_LEVEL_MINIMAL:
return "minimal";
- case WAL_LEVEL_ARCHIVE:
- return "archive";
case WAL_LEVEL_HOT_STANDBY:
return "hot_standby";
case WAL_LEVEL_LOGICAL:
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index 6dacee2..c74064a 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -120,7 +120,6 @@ extern int XLogArchiveMode;
typedef enum WalLevel
{
WAL_LEVEL_MINIMAL = 0,
- WAL_LEVEL_ARCHIVE,
WAL_LEVEL_HOT_STANDBY,
WAL_LEVEL_LOGICAL
} WalLevel;
@@ -128,17 +127,17 @@ extern int wal_level;
/* Is WAL archiving enabled (always or only while server is running normally)? */
#define XLogArchivingActive() \
- (XLogArchiveMode > ARCHIVE_MODE_OFF && wal_level >= WAL_LEVEL_ARCHIVE)
+ (AssertMacro(XLogArchiveMode == ARCHIVE_MODE_OFF || wal_level >= WAL_LEVEL_HOT_STANDBY), XLogArchiveMode > ARCHIVE_MODE_OFF)
/* Is WAL archiving enabled always (even during recovery)? */
#define XLogArchivingAlways() \
- (XLogArchiveMode == ARCHIVE_MODE_ALWAYS && wal_level >= WAL_LEVEL_ARCHIVE)
+ (AssertMacro(XLogArchiveMode == ARCHIVE_MODE_OFF || wal_level >= WAL_LEVEL_HOT_STANDBY), XLogArchiveMode == ARCHIVE_MODE_ALWAYS)
#define XLogArchiveCommandSet() (XLogArchiveCommand[0] != '\0')
/*
* Is WAL-logging necessary for archival or log-shipping, or can we skip
* WAL-logging if we fsync() the data before committing instead?
*/
-#define XLogIsNeeded() (wal_level >= WAL_LEVEL_ARCHIVE)
+#define XLogIsNeeded() (wal_level >= WAL_LEVEL_HOT_STANDBY)
/*
* Is a full-page image needed for hint bit updates?
--
2.5.1
On 1 September 2015 at 10:39, Peter Eisentraut <peter_e@gmx.net> wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1][snip]
Bike-shedding: In this patch, I removed "archive" and kept
"hot_standby", because that's what the previous discussions suggested.
Historically and semantically, it would be more correct the other way
around. On the other hand, keeping "hot_standby" would probably require
fewer configuration files to be changed. Or we could keep both, but
that would be confusing (for users and in the code).
We need to keep both, IMO, with 'archive' as an obsolete synonym for
hot_standby.
Otherwise pg_upgrade will get grumpy, and so will users who migrate
their configurations.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 2, 2015 at 2:21 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 1 September 2015 at 10:39, Peter Eisentraut <peter_e@gmx.net> wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1][snip]
Bike-shedding: In this patch, I removed "archive" and kept
"hot_standby", because that's what the previous discussions suggested.
Historically and semantically, it would be more correct the other way
around. On the other hand, keeping "hot_standby" would probably require
fewer configuration files to be changed. Or we could keep both, but
that would be confusing (for users and in the code).We need to keep both, IMO, with 'archive' as an obsolete synonym for
hot_standby.Otherwise pg_upgrade will get grumpy, and so will users who migrate
their configurations.
pg_upgradecluster has some logic to switch a parameter value (see
strrepl), and pg_upgrade does not handle parameter name switches by
itself, so the price to pay would be more maintenance annoyance for
existing upgrade scripts, which happens at more or less each major
release (checkpoint_segments removed in 9.5, unix_socket_directory
renamed in 9.3, etc.).
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2 November 2015 at 14:19, Michael Paquier <michael.paquier@gmail.com> wrote:
pg_upgradecluster has some logic to switch a parameter value (see
strrepl)
That's part of pg_wrapper, not core, though.
I'd quite like to see pg_wrapper become part of the PGDG RPMs, but
right now AFAIK it's a Debian-derived-only thing.
and pg_upgrade does not handle parameter name switches by
itself
Exactly.
so the price to pay would be more maintenance annoyance for
existing upgrade scripts, which happens at more or less each major
release (checkpoint_segments removed in 9.5, unix_socket_directory
renamed in 9.3, etc.).
Fair point. I'm not a great fan of how those changes affect users, but
I've also seen what too much backward compatibility can do to a
project. (Ref: Java, the Win32 APIs).
If users miss it then it won't explode anything in a way that's
dangerous or harmful, so I won't complain overly. I just wanted to
raise it as a possible concern.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/2/15 12:21 AM, Craig Ringer wrote:
On 1 September 2015 at 10:39, Peter Eisentraut <peter_e@gmx.net> wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1][snip]
Bike-shedding: In this patch, I removed "archive" and kept
"hot_standby", because that's what the previous discussions suggested.
Historically and semantically, it would be more correct the other way
around. On the other hand, keeping "hot_standby" would probably require
fewer configuration files to be changed. Or we could keep both, but
that would be confusing (for users and in the code).We need to keep both, IMO, with 'archive' as an obsolete synonym for
hot_standby.
I would prefer to rename 'hot_standby to 'archive' and make
'hot_standby' a deprecated synonym for the new 'archive' setting. This
prevents breakage in current configurations and avoids propagating a
misleading setting.
I see a fair number of installations with backup/archiving but no hot
standby (or any standby at all). There is often confusion when I
suggest setting 'wal_level' to 'hot_standby' to be better prepared for
the future. Admittedly these setups are becoming less common but they
are certainly out there.
--
-David
david@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 2, 2015 at 12:21 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
We need to keep both, IMO, with 'archive' as an obsolete synonym for
hot_standby.Otherwise pg_upgrade will get grumpy, and so will users who migrate
their configurations.
Removing options entirely arguably brings some worthwhile
simplification from a user perspective, but it's really unclear to me
that mapping the same set of options onto fewer underlying behaviors
buys us much. If we don't care enough about getting rid of archive to
force people to change postgresql.conf, I doubt whether this is buying
us enough to be worthwhile.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
Let's get something going.
I looked at this patch, which I think has got enough consensus that you
should just push forward with the proposed design -- in particular, just
remove one of archive or hot_standby values, not keep it as a synonym of
the other. If we're counting votes, I prefer keeping hot_standby over
archive.
The patch is nicely compact and applies, with only some fuzz.
I agree with changing all parts that say "XYZ or higher" to enumerate
the possible values.
It may be a good idea to have a look at Michael Paquier's recovery test
framework ( also in this commitfest: https://commitfest.postgresql.org/8/438/ )
and see how that is affected by this patch. Maybe the tests can find a
problem in this patch, and so perhaps you'd like to commit the tests
first, then this change on top.
I'm marking this as Ready for Committer, and setting you up as such for
this patch. If you would prefer not to commit, let me know and I can do
so.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Peter Eisentraut wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
Let's get something going.I looked at this patch, which I think has got enough consensus that you
should just push forward with the proposed design -- in particular, just
remove one of archive or hot_standby values, not keep it as a synonym of
the other. If we're counting votes, I prefer keeping hot_standby over
archive.
I see precisely 0 votes for that alternative upthread. I came the
closest of anyone to endorsing that proposal, I think, but my
preferred alternative is to change nothing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:Peter Eisentraut wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
Let's get something going.I looked at this patch, which I think has got enough consensus that you
should just push forward with the proposed design -- in particular, just
remove one of archive or hot_standby values, not keep it as a synonym of
the other. If we're counting votes, I prefer keeping hot_standby over
archive.I see precisely 0 votes for that alternative upthread. I came the
closest of anyone to endorsing that proposal, I think, but my
preferred alternative is to change nothing.
Hm? Perhaps the problem is that the thread stood on the shoulders of
larger threads. Andres Freund and Magnus Hagander both expressed,
independently, their desire to see one of these modes go away:
/messages/by-id/20150203124317.GA24767@awork2.anarazel.de
/messages/by-id/CABUevEy15Y=sF8doKjD86eujJZL=Tq2jyUSiYVkg6EVwVt=cag@mail.gmail.com
Actually, in the first of these threads
/messages/by-id/20150203124317.GA24767@awork2.anarazel.de
there's a lot of discussion about getting rid of wal_level completely
instead, but it doesn't look like there's any movement at all in that
direction. I think we should take this pretty small change that
improves things a bit in that direction, then others can continue to
propose further simplifications to our configuration in that area.
We could continue to do nothing, but then we've already been doing that
for some time and it hasn't changed things much.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 4, 2016 at 3:05 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Robert Haas wrote:
On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:Peter Eisentraut wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
Let's get something going.I looked at this patch, which I think has got enough consensus that you
should just push forward with the proposed design -- in particular, just
remove one of archive or hot_standby values, not keep it as a synonym of
the other. If we're counting votes, I prefer keeping hot_standby over
archive.I see precisely 0 votes for that alternative upthread. I came the
closest of anyone to endorsing that proposal, I think, but my
preferred alternative is to change nothing.Hm? Perhaps the problem is that the thread stood on the shoulders of
larger threads. Andres Freund and Magnus Hagander both expressed,
independently, their desire to see one of these modes go away:
/messages/by-id/20150203124317.GA24767@awork2.anarazel.de
/messages/by-id/CABUevEy15Y=sF8doKjD86eujJZL=Tq2jyUSiYVkg6EVwVt=cag@mail.gmail.com
OK, I see.
Actually, in the first of these threads
/messages/by-id/20150203124317.GA24767@awork2.anarazel.de
there's a lot of discussion about getting rid of wal_level completely
instead, but it doesn't look like there's any movement at all in that
direction. I think we should take this pretty small change that
improves things a bit in that direction, then others can continue to
propose further simplifications to our configuration in that area.We could continue to do nothing, but then we've already been doing that
for some time and it hasn't changed things much.
True. But it hasn't really caused much trouble either.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 5, 2016 at 1:04 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Peter Eisentraut wrote:
So we've had several rounds of discussions about simplifying replication
configuration in general and the wal_level setting in particular. [0][1]
Let's get something going.I looked at this patch, which I think has got enough consensus that you
should just push forward with the proposed design -- in particular, just
remove one of archive or hot_standby values, not keep it as a synonym of
the other. If we're counting votes, I prefer keeping hot_standby over
archive.
FWIW I have advocated for the simple removal of 'archive' :)
The patch is nicely compact and applies, with only some fuzz.
I agree with changing all parts that say "XYZ or higher" to enumerate
the possible values.
Yep.
It may be a good idea to have a look at Michael Paquier's recovery test
framework ( also in this commitfest: https://commitfest.postgresql.org/8/438/ )
and see how that is affected by this patch. Maybe the tests can find a
problem in this patch, and so perhaps you'd like to commit the tests
first, then this change on top.
Those would need a rebase if this patch stays as is. I'll take actions
as needed.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1 September 2015 at 03:39, Peter Eisentraut <peter_e@gmx.net> wrote:
- The distinction between wal_level settings "archive" and "hot_standby"
is in the way of automation or better intelligence, because the primary
cannot tell what the receiver intends to do with the WAL.So here is a patch to get rid of the distinction.
Bike-shedding: In this patch, I removed "archive" and kept
"hot_standby", because that's what the previous discussions suggested.
Historically and semantically, it would be more correct the other way
around. On the other hand, keeping "hot_standby" would probably require
fewer configuration files to be changed. Or we could keep both, but
that would be confusing (for users and in the code).
I've reviewed this and have a few comments.
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.
What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed in a
later release.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 26-01-2016 12:56, Simon Riggs wrote:
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.
Agree.
What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.
3. Add a WARNING at startup (until removal of values) saying something
like "'archive' value is deprecated and will be removed in a future
version. Use 'replica' value instead."
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/26/16 10:56 AM, Simon Riggs wrote:
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.
I'm pretty sure nothing would break, but I do agree that it could be
confusing.
What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
I have been leaning toward making up a new name, too, but hadn't found a
good one. I tend to like "replica", though.
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.
If we do 1, then we might as well get rid of the old names right away.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 28, 2016 at 10:53 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 1/26/16 10:56 AM, Simon Riggs wrote:
What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)I have been leaning toward making up a new name, too, but hadn't found a
good one. I tend to like "replica", though.
"replica" sounds nice.
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.If we do 1, then we might as well get rid of the old names right away.
+1.
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/26/16 10:56 AM, Simon Riggs wrote:
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.
Updated patch to reflect these suggestions.
Attachments:
v2-0001-Merge-wal_level-archive-and-hot_standby-into-new-.patchapplication/x-patch; name=v2-0001-Merge-wal_level-archive-and-hot_standby-into-new-.patchDownload
From a1df946bc77cb51ca149a52276175a001942d8d0 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 7 Feb 2016 10:09:05 -0500
Subject: [PATCH v2] Merge wal_level "archive" and "hot_standby" into new name
"replica"
The distinction between "archive" and "hot_standby" existed only because
at the time "hot_standby" was added, there was some uncertainty about
stability. This is now a long time ago. We would like to move forward
with simplifying the replication configuration, but this distinction is
in the way, because a primary server cannot tell (without asking a
standby or predicting the future) which one of these would be the
appropriate level.
Pick a new name for the combined setting to make it clearer that it
covers all (non-logical) backup and replication uses. The old values
are still accepted but are converted internally.
---
doc/src/sgml/backup.sgml | 2 +-
doc/src/sgml/config.sgml | 30 +++++++++++----------------
doc/src/sgml/high-availability.sgml | 2 +-
doc/src/sgml/ref/alter_system.sgml | 2 +-
doc/src/sgml/ref/pgupgrade.sgml | 2 +-
src/backend/access/rmgrdesc/xlogdesc.c | 5 +++--
src/backend/access/transam/xact.c | 2 +-
src/backend/access/transam/xlog.c | 20 ++++++++----------
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/postmaster.c | 2 +-
src/backend/replication/slot.c | 5 -----
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 2 +-
src/bin/pg_controldata/pg_controldata.c | 6 ++----
src/bin/pg_rewind/RewindTest.pm | 2 +-
src/include/access/xlog.h | 11 +++++-----
src/include/catalog/pg_control.h | 2 +-
17 files changed, 42 insertions(+), 57 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 7413666..46017a6 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1285,7 +1285,7 @@ <title>Standalone Hot Backups</title>
If more flexibility in copying the backup files is needed, a lower
level process can be used for standalone hot backups as well.
To prepare for low level standalone hot backups, set <varname>wal_level</> to
- <literal>archive</> or higher, <varname>archive_mode</> to
+ <literal>replica</> or higher, <varname>archive_mode</> to
<literal>on</>, and set up an <varname>archive_command</> that performs
archiving only when a <emphasis>switch file</> exists. For example:
<programlisting>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 392eb70..bed7436 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1971,9 +1971,9 @@ <title>Settings</title>
<varname>wal_level</> determines how much information is written
to the WAL. The default value is <literal>minimal</>, which writes
only the information needed to recover from a crash or immediate
- shutdown. <literal>archive</> adds logging required for WAL archiving;
- <literal>hot_standby</> further adds information required to run
- read-only queries on a standby server; and, finally
+ shutdown. <literal>replica</> adds logging required for WAL
+ archiving as well as information required to run
+ read-only queries on a standby server. Finally,
<literal>logical</> adds information necessary to support logical
decoding. Each level includes the information logged at all lower
levels. This parameter can only be set at server start.
@@ -1991,30 +1991,24 @@ <title>Settings</title>
transaction</member>
</simplelist>
But minimal WAL does not contain enough information to reconstruct the
- data from a base backup and the WAL logs, so <literal>archive</> or
+ data from a base backup and the WAL logs, so <literal>replica</> or
higher must be used to enable WAL archiving
(<xref linkend="guc-archive-mode">) and streaming replication.
</para>
<para>
- In <literal>hot_standby</> level, the same information is logged as
- with <literal>archive</>, plus information needed to reconstruct
- the status of running transactions from the WAL. To enable read-only
- queries on a standby server, <varname>wal_level</> must be set to
- <literal>hot_standby</> or higher on the primary, and
- <xref linkend="guc-hot-standby"> must be enabled in the standby. It is
- thought that there is little measurable difference in performance
- between using <literal>hot_standby</> and <literal>archive</> levels,
- so feedback is welcome if any production impacts are noticeable.
- </para>
- <para>
In <literal>logical</> level, the same information is logged as
- with <literal>hot_standby</>, plus information needed to allow
+ with <literal>replica</>, plus information needed to allow
extracting logical change sets from the WAL. Using a level of
<literal>logical</> will increase the WAL volume, particularly if many
tables are configured for <literal>REPLICA IDENTITY FULL</literal> and
many <command>UPDATE</> and <command>DELETE</> statements are
executed.
</para>
+ <para>
+ In releases prior to 9.6, this parameter also allowed the
+ values <literal>archive</literal> and <literal>hot_standby</literal>.
+ These are still accepted but mapped to <literal>replica</literal>.
+ </para>
</listitem>
</varlistentry>
@@ -2674,7 +2668,7 @@ <title>Sending Server(s)</title>
higher than the maximum number of expected clients so disconnected
clients can immediately reconnect. This parameter can only
be set at server start. <varname>wal_level</> must be set to
- <literal>archive</> or higher to allow connections from standby
+ <literal>replica</> or higher to allow connections from standby
servers.
</para>
</listitem>
@@ -2693,7 +2687,7 @@ <title>Sending Server(s)</title>
can support. The default is zero. This parameter can only be set at
server start.
<varname>wal_level</varname> must be set
- to <literal>archive</literal> or higher to allow replication slots to
+ to <literal>replica</literal> or higher to allow replication slots to
be used. Setting it to a lower value than the number of currently
existing replication slots will prevent the server from starting.
</para>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 6cb690c..19d613e 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1988,7 +1988,7 @@ <title>Administrator's Overview</title>
Consistency information is recorded once per checkpoint on the primary.
It is not possible to enable hot standby when reading WAL
written during a period when <varname>wal_level</> was not set to
- <literal>hot_standby</> or <literal>logical</> on the primary. Reaching
+ <literal>replica</> or <literal>logical</> on the primary. Reaching
a consistent state can also be delayed in the presence of both of these
conditions:
diff --git a/doc/src/sgml/ref/alter_system.sgml b/doc/src/sgml/ref/alter_system.sgml
index f6a018f..00fd8d7 100644
--- a/doc/src/sgml/ref/alter_system.sgml
+++ b/doc/src/sgml/ref/alter_system.sgml
@@ -108,7 +108,7 @@ <title>Examples</title>
<para>
Set the <literal>wal_level</>:
<programlisting>
-ALTER SYSTEM SET wal_level = hot_standby;
+ALTER SYSTEM SET wal_level = replica;
</programlisting>
</para>
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index eb113c2..b99e546 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -477,7 +477,7 @@ <title>Start and stop the new master cluster</title>
<para>
In the new master cluster, change <varname>wal_level</> to
- <literal>hot_standby</> in the <filename>postgresql.conf</> file
+ <literal>replica</> in the <filename>postgresql.conf</> file
and then start and stop the cluster.
</para>
</step>
diff --git a/src/backend/access/rmgrdesc/xlogdesc.c b/src/backend/access/rmgrdesc/xlogdesc.c
index b694dea..1953e86 100644
--- a/src/backend/access/rmgrdesc/xlogdesc.c
+++ b/src/backend/access/rmgrdesc/xlogdesc.c
@@ -25,8 +25,9 @@
*/
const struct config_enum_entry wal_level_options[] = {
{"minimal", WAL_LEVEL_MINIMAL, false},
- {"archive", WAL_LEVEL_ARCHIVE, false},
- {"hot_standby", WAL_LEVEL_HOT_STANDBY, false},
+ {"replica", WAL_LEVEL_REPLICA, false},
+ {"archive", WAL_LEVEL_REPLICA, true}, /* deprecated */
+ {"hot_standby", WAL_LEVEL_REPLICA, true}, /* deprecated */
{"logical", WAL_LEVEL_LOGICAL, false},
{NULL, 0, false}
};
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index b0d5440..1f27563 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -1254,7 +1254,7 @@ RecordTransactionCommit(void)
* this case, but we don't currently try to do that. It would certainly
* cause problems at least in Hot Standby mode, where the
* KnownAssignedXids machinery requires tracking every XID assignment. It
- * might be OK to skip it only when wal_level < hot_standby, but for now
+ * might be OK to skip it only when wal_level < replica, but for now
* we don't.)
*
* However, if we're doing cleanup of any non-temp rels or committing any
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index a2846c4..5cee5b0 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5836,7 +5836,7 @@ static void
CheckRequiredParameterValues(void)
{
/*
- * For archive recovery, the WAL must be generated with at least 'archive'
+ * For archive recovery, the WAL must be generated with at least 'replica'
* wal_level.
*/
if (ArchiveRecoveryRequested && ControlFile->wal_level == WAL_LEVEL_MINIMAL)
@@ -5847,15 +5847,15 @@ CheckRequiredParameterValues(void)
}
/*
- * For Hot Standby, the WAL must be generated with 'hot_standby' mode, and
+ * For Hot Standby, the WAL must be generated with 'replica' mode, and
* we must have at least as many backend slots as the primary.
*/
if (ArchiveRecoveryRequested && EnableHotStandby)
{
- if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
+ if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
ereport(ERROR,
- (errmsg("hot standby is not possible because wal_level was not set to \"hot_standby\" or higher on the master server"),
- errhint("Either set wal_level to \"hot_standby\" on the master, or turn off hot_standby here.")));
+ (errmsg("hot standby is not possible because wal_level was not set to \"replica\" or higher on the master server"),
+ errhint("Either set wal_level to \"replica\" on the master, or turn off hot_standby here.")));
/* We ignore autovacuum_max_workers when we make this test. */
RecoveryRequiresIntParameter("max_connections",
@@ -9445,10 +9445,8 @@ xlog_redo(XLogReaderState *record)
/*
* Update minRecoveryPoint to ensure that if recovery is aborted, we
* recover back up to this point before allowing hot standby again.
- * This is particularly important if wal_level was set to 'archive'
- * before, and is now 'hot_standby', to ensure you don't run queries
- * against the WAL preceding the wal_level change. Same applies to
- * decreasing max_* settings.
+ * This is important if the max_* settings are decreased, to ensure
+ * you don't run queries against the WAL preceding the change.
*/
minRecoveryPoint = ControlFile->minRecoveryPoint;
minRecoveryPointTLI = ControlFile->minRecoveryPointTLI;
@@ -9779,7 +9777,7 @@ do_pg_start_backup(const char *backupidstr, bool fast, TimeLineID *starttli_p,
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for making an online backup"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"replica\" or \"logical\" at server start.")));
if (strlen(backupidstr) > MAXPGPATH)
ereport(ERROR,
@@ -10250,7 +10248,7 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for making an online backup"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"replica\" or \"logical\" at server start.")));
/*
* OK to update backup counters and forcePageWrites
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 31cbb01..9ec6b2a 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -154,7 +154,7 @@ pg_create_restore_point(PG_FUNCTION_ARGS)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for creating a restore point"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"replica\" or \"logical\" at server start.")));
restore_name_str = text_to_cstring(restore_name);
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b16fc28..6cf51e1 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -858,7 +858,7 @@ PostmasterMain(int argc, char *argv[])
(errmsg("WAL archival cannot be enabled when wal_level is \"minimal\"")));
if (max_wal_senders > 0 && wal_level == WAL_LEVEL_MINIMAL)
ereport(ERROR,
- (errmsg("WAL streaming (max_wal_senders > 0) requires wal_level \"archive\", \"hot_standby\", or \"logical\"")));
+ (errmsg("WAL streaming (max_wal_senders > 0) requires wal_level \"replica\" or \"logical\"")));
/*
* Other one-time internal sanity checks can go here, if they are fast.
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 11b44a4..5ca5e13 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -759,11 +759,6 @@ CheckSlotRequirements(void)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
(errmsg("replication slots can only be used if max_replication_slots > 0"))));
-
- if (wal_level < WAL_LEVEL_ARCHIVE)
- ereport(ERROR,
- (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("replication slots can only be used if wal_level >= archive")));
}
/*
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index 029114f..0c2500a 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -173,7 +173,7 @@
# - Settings -
-#wal_level = minimal # minimal, archive, hot_standby, or logical
+#wal_level = minimal # minimal, replica, or logical
# (change requires restart)
#fsync = on # turns forced synchronization on or off
#synchronous_commit = on # synchronization level;
diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
index a275077..e26b875 100644
--- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
@@ -43,7 +43,7 @@
open CONF, ">>$pgdata/postgresql.conf";
print CONF "max_replication_slots = 10\n";
print CONF "max_wal_senders = 10\n";
-print CONF "wal_level = archive\n";
+print CONF "wal_level = replica\n";
close CONF;
$node->restart;
diff --git a/src/bin/pg_controldata/pg_controldata.c b/src/bin/pg_controldata/pg_controldata.c
index e7e072f..b6b6173 100644
--- a/src/bin/pg_controldata/pg_controldata.c
+++ b/src/bin/pg_controldata/pg_controldata.c
@@ -75,10 +75,8 @@ wal_level_str(WalLevel wal_level)
{
case WAL_LEVEL_MINIMAL:
return "minimal";
- case WAL_LEVEL_ARCHIVE:
- return "archive";
- case WAL_LEVEL_HOT_STANDBY:
- return "hot_standby";
+ case WAL_LEVEL_REPLICA:
+ return "replica";
case WAL_LEVEL_LOGICAL:
return "logical";
}
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
index 68834cd..c740b64 100644
--- a/src/bin/pg_rewind/RewindTest.pm
+++ b/src/bin/pg_rewind/RewindTest.pm
@@ -122,7 +122,7 @@ sub setup_cluster
# Custom parameters for master's postgresql.conf
$node_master->append_conf(
"postgresql.conf", qq(
-wal_level = hot_standby
+wal_level = replica
max_wal_senders = 2
wal_keep_segments = 20
max_wal_size = 200MB
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index ecd30ce..74a1394 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -121,25 +121,24 @@ extern int XLogArchiveMode;
typedef enum WalLevel
{
WAL_LEVEL_MINIMAL = 0,
- WAL_LEVEL_ARCHIVE,
- WAL_LEVEL_HOT_STANDBY,
+ WAL_LEVEL_REPLICA,
WAL_LEVEL_LOGICAL
} WalLevel;
extern int wal_level;
/* Is WAL archiving enabled (always or only while server is running normally)? */
#define XLogArchivingActive() \
- (XLogArchiveMode > ARCHIVE_MODE_OFF && wal_level >= WAL_LEVEL_ARCHIVE)
+ (AssertMacro(XLogArchiveMode == ARCHIVE_MODE_OFF || wal_level >= WAL_LEVEL_REPLICA), XLogArchiveMode > ARCHIVE_MODE_OFF)
/* Is WAL archiving enabled always (even during recovery)? */
#define XLogArchivingAlways() \
- (XLogArchiveMode == ARCHIVE_MODE_ALWAYS && wal_level >= WAL_LEVEL_ARCHIVE)
+ (AssertMacro(XLogArchiveMode == ARCHIVE_MODE_OFF || wal_level >= WAL_LEVEL_REPLICA), XLogArchiveMode == ARCHIVE_MODE_ALWAYS)
#define XLogArchiveCommandSet() (XLogArchiveCommand[0] != '\0')
/*
* Is WAL-logging necessary for archival or log-shipping, or can we skip
* WAL-logging if we fsync() the data before committing instead?
*/
-#define XLogIsNeeded() (wal_level >= WAL_LEVEL_ARCHIVE)
+#define XLogIsNeeded() (wal_level >= WAL_LEVEL_REPLICA)
/*
* Is a full-page image needed for hint bit updates?
@@ -153,7 +152,7 @@ extern int wal_level;
#define XLogHintBitIsNeeded() (DataChecksumsEnabled() || wal_log_hints)
/* Do we need to WAL-log information required only for Hot Standby and logical replication? */
-#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_HOT_STANDBY)
+#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_REPLICA)
/* Do we need to WAL-log information required only for logical replication? */
#define XLogLogicalInfoActive() (wal_level >= WAL_LEVEL_LOGICAL)
diff --git a/src/include/catalog/pg_control.h b/src/include/catalog/pg_control.h
index 86fbdce..7ba396d 100644
--- a/src/include/catalog/pg_control.h
+++ b/src/include/catalog/pg_control.h
@@ -54,7 +54,7 @@ typedef struct CheckPoint
/*
* Oldest XID still running. This is only needed to initialize hot standby
* mode from an online checkpoint, so we only bother calculating this for
- * online checkpoints and only when wal_level is hot_standby. Otherwise
+ * online checkpoints and only when wal_level is replica. Otherwise
* it's set to InvalidTransactionId.
*/
TransactionId oldestActiveXid;
--
2.7.1
On Mon, Feb 8, 2016 at 6:47 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 1/26/16 10:56 AM, Simon Riggs wrote:
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.Updated patch to reflect these suggestions.
Shouldn't backup.sgml be updated as well? Here is the portion that I
am referring to:
To enable WAL archiving, set the <xref linkend="guc-wal-level">
configuration parameter to <literal>archive</> or higher,
<xref linkend="guc-archive-mode"> to <literal>on</>,
But minimal WAL does not contain enough information to reconstruct the
- data from a base backup and the WAL logs, so <literal>archive</> or
+ data from a base backup and the WAL logs, so <literal>replica</> or
higher must be used to enable WAL archiving
(<xref linkend="guc-archive-mode">) and streaming replication.
</para>
<para>
- In <literal>hot_standby</> level, the same information is logged as
- with <literal>archive</>, plus information needed to reconstruct
- the status of running transactions from the WAL. To enable read-only
As the paragraph about the difference between hot_standby and archive
is removed, I think that it would be better to mention that setting
wal_level to replica allows to reconstruct data from a base backup and
the WAL logs, *and* to run read-only queries when hot_standby is
enabled.- if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
+ if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
Upthread it was mentioned that switching to an approach where enum
values are directly listed would be better. The target of an extra
patch on top of this one?- if (wal_level < WAL_LEVEL_ARCHIVE)
- ereport(ERROR,
-
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("replication slots can only be
used if wal_level >= archive")));
We should still forbid the creation of replication slots if wal_level = minimal.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/7/16 4:47 PM, Peter Eisentraut wrote:
On 1/26/16 10:56 AM, Simon Riggs wrote:
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.Updated patch to reflect these suggestions.
-#define XLogIsNeeded() (wal_level >= WAL_LEVEL_ARCHIVE)
+#define XLogIsNeeded() (wal_level >= WAL_LEVEL_REPLICA)
<...>
-#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_HOT_STANDBY)
+#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_REPLICA)Since these are identical now shouldn't one be removed? I searched the
code and I couldn't find anything that looked dead (i.e. XLogIsNeeded()
&& !XLogStandbyInfoActive()) but it still seems like having both could
cause confusion.
--
-David
david@pgmasters.net
Peter Eisentraut wrote:
On 1/26/16 10:56 AM, Simon Riggs wrote:
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.Updated patch to reflect these suggestions.
I wonder if the "keep one / keep both" argument is running in circles as
new reviewers arrive at the thread. Perhaps somebody could read the
whole thread(s) and figure out a way to find consensus so that we move
forward on this.
I've closed it as returned-with-feedback for now. Please resubmit to
next CF.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/8/16 9:36 AM, David Steele wrote:
-#define XLogIsNeeded() (wal_level >= WAL_LEVEL_ARCHIVE) +#define XLogIsNeeded() (wal_level >= WAL_LEVEL_REPLICA) <...> -#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_HOT_STANDBY) +#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_REPLICA)Since these are identical now shouldn't one be removed? I searched the
code and I couldn't find anything that looked dead (i.e. XLogIsNeeded()
&& !XLogStandbyInfoActive()) but it still seems like having both could
cause confusion.
I think this should eventually be cleaned up, but it doesn't seem
necessary in the first patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/8/16 7:34 AM, Michael Paquier wrote:
Shouldn't backup.sgml be updated as well? Here is the portion that I
am referring to:
To enable WAL archiving, set the <xref linkend="guc-wal-level">
configuration parameter to <literal>archive</> or higher,
<xref linkend="guc-archive-mode"> to <literal>on</>,But minimal WAL does not contain enough information to reconstruct the - data from a base backup and the WAL logs, so <literal>archive</> or + data from a base backup and the WAL logs, so <literal>replica</> or higher must be used to enable WAL archiving (<xref linkend="guc-archive-mode">) and streaming replication. </para>
Checked for leftovers again and fixed one.
<para>
- In <literal>hot_standby</> level, the same information is logged as
- with <literal>archive</>, plus information needed to reconstruct
- the status of running transactions from the WAL. To enable read-only
As the paragraph about the difference between hot_standby and archive
is removed, I think that it would be better to mention that setting
wal_level to replica allows to reconstruct data from a base backup and
the WAL logs, *and* to run read-only queries when hot_standby is
enabled.
Well, I think that is really only of historical interest. The
assumption is, as long as hot_standby = on, you can run read-only
queries. The WAL level is taken completely out of the mental
consideration, because if you have replicate at all, it's good enough.
That is part of the point of this patch.
- if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY) + if (ControlFile->wal_level < WAL_LEVEL_REPLICA) Upthread it was mentioned that switching to an approach where enum values are directly listed would be better. The target of an extra patch on top of this one?
I'm not sure what is meant by that.
- if (wal_level < WAL_LEVEL_ARCHIVE)
- ereport(ERROR,
-
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("replication slots can only be
used if wal_level >= archive")));
We should still forbid the creation of replication slots if wal_level = minimal.
I think I took this out because you actually can't get to that check,
but I put it back in because it seems better for clarity.
Attachments:
0001-Merge-wal_level-archive-and-hot_standby-into-new-nam.patchapplication/x-patch; name=0001-Merge-wal_level-archive-and-hot_standby-into-new-nam.patchDownload
From 574dd447b4a077267200d2ca9b8b4e185d4bb052 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 29 Feb 2016 20:01:54 -0500
Subject: [PATCH] Merge wal_level "archive" and "hot_standby" into new name
"replica"
The distinction between "archive" and "hot_standby" existed only because
at the time "hot_standby" was added, there was some uncertainty about
stability. This is now a long time ago. We would like to move forward
with simplifying the replication configuration, but this distinction is
in the way, because a primary server cannot tell (without asking a
standby or predicting the future) which one of these would be the
appropriate level.
Pick a new name for the combined setting to make it clearer that it
covers all (non-logical) backup and replication uses. The old values
are still accepted but are converted internally.
---
doc/src/sgml/backup.sgml | 4 ++--
doc/src/sgml/config.sgml | 30 +++++++++++----------------
doc/src/sgml/high-availability.sgml | 2 +-
doc/src/sgml/ref/alter_system.sgml | 2 +-
doc/src/sgml/ref/pgupgrade.sgml | 2 +-
src/backend/access/rmgrdesc/xlogdesc.c | 5 +++--
src/backend/access/transam/xact.c | 2 +-
src/backend/access/transam/xlog.c | 20 ++++++++----------
src/backend/access/transam/xlogfuncs.c | 2 +-
src/backend/postmaster/postmaster.c | 2 +-
src/backend/replication/slot.c | 2 +-
src/backend/utils/misc/postgresql.conf.sample | 2 +-
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 2 +-
src/bin/pg_controldata/pg_controldata.c | 6 ++----
src/include/access/xlog.h | 11 +++++-----
src/include/catalog/pg_control.h | 2 +-
src/test/perl/PostgresNode.pm | 2 +-
17 files changed, 44 insertions(+), 54 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 7413666..9092cf8 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -592,7 +592,7 @@ <title>Setting Up WAL Archiving</title>
<para>
To enable WAL archiving, set the <xref linkend="guc-wal-level">
- configuration parameter to <literal>archive</> or higher,
+ configuration parameter to <literal>replica</> or higher,
<xref linkend="guc-archive-mode"> to <literal>on</>,
and specify the shell command to use in the <xref
linkend="guc-archive-command"> configuration parameter. In practice
@@ -1285,7 +1285,7 @@ <title>Standalone Hot Backups</title>
If more flexibility in copying the backup files is needed, a lower
level process can be used for standalone hot backups as well.
To prepare for low level standalone hot backups, set <varname>wal_level</> to
- <literal>archive</> or higher, <varname>archive_mode</> to
+ <literal>replica</> or higher, <varname>archive_mode</> to
<literal>on</>, and set up an <varname>archive_command</> that performs
archiving only when a <emphasis>switch file</> exists. For example:
<programlisting>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index a09ceb2..04f2566 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1971,9 +1971,9 @@ <title>Settings</title>
<varname>wal_level</> determines how much information is written
to the WAL. The default value is <literal>minimal</>, which writes
only the information needed to recover from a crash or immediate
- shutdown. <literal>archive</> adds logging required for WAL archiving;
- <literal>hot_standby</> further adds information required to run
- read-only queries on a standby server; and, finally
+ shutdown. <literal>replica</> adds logging required for WAL
+ archiving as well as information required to run
+ read-only queries on a standby server. Finally,
<literal>logical</> adds information necessary to support logical
decoding. Each level includes the information logged at all lower
levels. This parameter can only be set at server start.
@@ -1991,30 +1991,24 @@ <title>Settings</title>
transaction</member>
</simplelist>
But minimal WAL does not contain enough information to reconstruct the
- data from a base backup and the WAL logs, so <literal>archive</> or
+ data from a base backup and the WAL logs, so <literal>replica</> or
higher must be used to enable WAL archiving
(<xref linkend="guc-archive-mode">) and streaming replication.
</para>
<para>
- In <literal>hot_standby</> level, the same information is logged as
- with <literal>archive</>, plus information needed to reconstruct
- the status of running transactions from the WAL. To enable read-only
- queries on a standby server, <varname>wal_level</> must be set to
- <literal>hot_standby</> or higher on the primary, and
- <xref linkend="guc-hot-standby"> must be enabled in the standby. It is
- thought that there is little measurable difference in performance
- between using <literal>hot_standby</> and <literal>archive</> levels,
- so feedback is welcome if any production impacts are noticeable.
- </para>
- <para>
In <literal>logical</> level, the same information is logged as
- with <literal>hot_standby</>, plus information needed to allow
+ with <literal>replica</>, plus information needed to allow
extracting logical change sets from the WAL. Using a level of
<literal>logical</> will increase the WAL volume, particularly if many
tables are configured for <literal>REPLICA IDENTITY FULL</literal> and
many <command>UPDATE</> and <command>DELETE</> statements are
executed.
</para>
+ <para>
+ In releases prior to 9.6, this parameter also allowed the
+ values <literal>archive</literal> and <literal>hot_standby</literal>.
+ These are still accepted but mapped to <literal>replica</literal>.
+ </para>
</listitem>
</varlistentry>
@@ -2697,7 +2691,7 @@ <title>Sending Server(s)</title>
higher than the maximum number of expected clients so disconnected
clients can immediately reconnect. This parameter can only
be set at server start. <varname>wal_level</> must be set to
- <literal>archive</> or higher to allow connections from standby
+ <literal>replica</> or higher to allow connections from standby
servers.
</para>
</listitem>
@@ -2716,7 +2710,7 @@ <title>Sending Server(s)</title>
can support. The default is zero. This parameter can only be set at
server start.
<varname>wal_level</varname> must be set
- to <literal>archive</literal> or higher to allow replication slots to
+ to <literal>replica</literal> or higher to allow replication slots to
be used. Setting it to a lower value than the number of currently
existing replication slots will prevent the server from starting.
</para>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 6cb690c..19d613e 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1988,7 +1988,7 @@ <title>Administrator's Overview</title>
Consistency information is recorded once per checkpoint on the primary.
It is not possible to enable hot standby when reading WAL
written during a period when <varname>wal_level</> was not set to
- <literal>hot_standby</> or <literal>logical</> on the primary. Reaching
+ <literal>replica</> or <literal>logical</> on the primary. Reaching
a consistent state can also be delayed in the presence of both of these
conditions:
diff --git a/doc/src/sgml/ref/alter_system.sgml b/doc/src/sgml/ref/alter_system.sgml
index f6a018f..00fd8d7 100644
--- a/doc/src/sgml/ref/alter_system.sgml
+++ b/doc/src/sgml/ref/alter_system.sgml
@@ -108,7 +108,7 @@ <title>Examples</title>
<para>
Set the <literal>wal_level</>:
<programlisting>
-ALTER SYSTEM SET wal_level = hot_standby;
+ALTER SYSTEM SET wal_level = replica;
</programlisting>
</para>
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index eb113c2..b99e546 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -477,7 +477,7 @@ <title>Start and stop the new master cluster</title>
<para>
In the new master cluster, change <varname>wal_level</> to
- <literal>hot_standby</> in the <filename>postgresql.conf</> file
+ <literal>replica</> in the <filename>postgresql.conf</> file
and then start and stop the cluster.
</para>
</step>
diff --git a/src/backend/access/rmgrdesc/xlogdesc.c b/src/backend/access/rmgrdesc/xlogdesc.c
index 2dcbfbd..022bd44 100644
--- a/src/backend/access/rmgrdesc/xlogdesc.c
+++ b/src/backend/access/rmgrdesc/xlogdesc.c
@@ -25,8 +25,9 @@
*/
const struct config_enum_entry wal_level_options[] = {
{"minimal", WAL_LEVEL_MINIMAL, false},
- {"archive", WAL_LEVEL_ARCHIVE, false},
- {"hot_standby", WAL_LEVEL_HOT_STANDBY, false},
+ {"replica", WAL_LEVEL_REPLICA, false},
+ {"archive", WAL_LEVEL_REPLICA, true}, /* deprecated */
+ {"hot_standby", WAL_LEVEL_REPLICA, true}, /* deprecated */
{"logical", WAL_LEVEL_LOGICAL, false},
{NULL, 0, false}
};
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index b0d5440..1f27563 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -1254,7 +1254,7 @@ RecordTransactionCommit(void)
* this case, but we don't currently try to do that. It would certainly
* cause problems at least in Hot Standby mode, where the
* KnownAssignedXids machinery requires tracking every XID assignment. It
- * might be OK to skip it only when wal_level < hot_standby, but for now
+ * might be OK to skip it only when wal_level < replica, but for now
* we don't.)
*
* However, if we're doing cleanup of any non-temp rels or committing any
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 94b79ac..40dabca 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5884,7 +5884,7 @@ static void
CheckRequiredParameterValues(void)
{
/*
- * For archive recovery, the WAL must be generated with at least 'archive'
+ * For archive recovery, the WAL must be generated with at least 'replica'
* wal_level.
*/
if (ArchiveRecoveryRequested && ControlFile->wal_level == WAL_LEVEL_MINIMAL)
@@ -5895,15 +5895,15 @@ CheckRequiredParameterValues(void)
}
/*
- * For Hot Standby, the WAL must be generated with 'hot_standby' mode, and
+ * For Hot Standby, the WAL must be generated with 'replica' mode, and
* we must have at least as many backend slots as the primary.
*/
if (ArchiveRecoveryRequested && EnableHotStandby)
{
- if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
+ if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
ereport(ERROR,
- (errmsg("hot standby is not possible because wal_level was not set to \"hot_standby\" or higher on the master server"),
- errhint("Either set wal_level to \"hot_standby\" on the master, or turn off hot_standby here.")));
+ (errmsg("hot standby is not possible because wal_level was not set to \"replica\" or higher on the master server"),
+ errhint("Either set wal_level to \"replica\" on the master, or turn off hot_standby here.")));
/* We ignore autovacuum_max_workers when we make this test. */
RecoveryRequiresIntParameter("max_connections",
@@ -9489,10 +9489,8 @@ xlog_redo(XLogReaderState *record)
/*
* Update minRecoveryPoint to ensure that if recovery is aborted, we
* recover back up to this point before allowing hot standby again.
- * This is particularly important if wal_level was set to 'archive'
- * before, and is now 'hot_standby', to ensure you don't run queries
- * against the WAL preceding the wal_level change. Same applies to
- * decreasing max_* settings.
+ * This is important if the max_* settings are decreased, to ensure
+ * you don't run queries against the WAL preceding the change.
*/
minRecoveryPoint = ControlFile->minRecoveryPoint;
minRecoveryPointTLI = ControlFile->minRecoveryPointTLI;
@@ -9823,7 +9821,7 @@ do_pg_start_backup(const char *backupidstr, bool fast, TimeLineID *starttli_p,
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for making an online backup"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"replica\" or \"logical\" at server start.")));
if (strlen(backupidstr) > MAXPGPATH)
ereport(ERROR,
@@ -10294,7 +10292,7 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for making an online backup"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"replica\" or \"logical\" at server start.")));
/*
* OK to update backup counters and forcePageWrites
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 31cbb01..9ec6b2a 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -154,7 +154,7 @@ pg_create_restore_point(PG_FUNCTION_ARGS)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("WAL level not sufficient for creating a restore point"),
- errhint("wal_level must be set to \"archive\", \"hot_standby\", or \"logical\" at server start.")));
+ errhint("wal_level must be set to \"replica\" or \"logical\" at server start.")));
restore_name_str = text_to_cstring(restore_name);
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b16fc28..6cf51e1 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -858,7 +858,7 @@ PostmasterMain(int argc, char *argv[])
(errmsg("WAL archival cannot be enabled when wal_level is \"minimal\"")));
if (max_wal_senders > 0 && wal_level == WAL_LEVEL_MINIMAL)
ereport(ERROR,
- (errmsg("WAL streaming (max_wal_senders > 0) requires wal_level \"archive\", \"hot_standby\", or \"logical\"")));
+ (errmsg("WAL streaming (max_wal_senders > 0) requires wal_level \"replica\" or \"logical\"")));
/*
* Other one-time internal sanity checks can go here, if they are fast.
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index affa9b9..c9ff45c 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -760,7 +760,7 @@ CheckSlotRequirements(void)
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
(errmsg("replication slots can only be used if max_replication_slots > 0"))));
- if (wal_level < WAL_LEVEL_ARCHIVE)
+ if (wal_level < WAL_LEVEL_REPLICA)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("replication slots can only be used if wal_level >= archive")));
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index ee3d378..25b74ff 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -173,7 +173,7 @@
# - Settings -
-#wal_level = minimal # minimal, archive, hot_standby, or logical
+#wal_level = minimal # minimal, replica, or logical
# (change requires restart)
#fsync = on # turns forced synchronization on or off
#synchronous_commit = on # synchronization level;
diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
index a275077..e26b875 100644
--- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
@@ -43,7 +43,7 @@
open CONF, ">>$pgdata/postgresql.conf";
print CONF "max_replication_slots = 10\n";
print CONF "max_wal_senders = 10\n";
-print CONF "wal_level = archive\n";
+print CONF "wal_level = replica\n";
close CONF;
$node->restart;
diff --git a/src/bin/pg_controldata/pg_controldata.c b/src/bin/pg_controldata/pg_controldata.c
index 5dd2dbc..0ea3ce9 100644
--- a/src/bin/pg_controldata/pg_controldata.c
+++ b/src/bin/pg_controldata/pg_controldata.c
@@ -75,10 +75,8 @@ wal_level_str(WalLevel wal_level)
{
case WAL_LEVEL_MINIMAL:
return "minimal";
- case WAL_LEVEL_ARCHIVE:
- return "archive";
- case WAL_LEVEL_HOT_STANDBY:
- return "hot_standby";
+ case WAL_LEVEL_REPLICA:
+ return "replica";
case WAL_LEVEL_LOGICAL:
return "logical";
}
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index ecd30ce..74a1394 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -121,25 +121,24 @@ extern int XLogArchiveMode;
typedef enum WalLevel
{
WAL_LEVEL_MINIMAL = 0,
- WAL_LEVEL_ARCHIVE,
- WAL_LEVEL_HOT_STANDBY,
+ WAL_LEVEL_REPLICA,
WAL_LEVEL_LOGICAL
} WalLevel;
extern int wal_level;
/* Is WAL archiving enabled (always or only while server is running normally)? */
#define XLogArchivingActive() \
- (XLogArchiveMode > ARCHIVE_MODE_OFF && wal_level >= WAL_LEVEL_ARCHIVE)
+ (AssertMacro(XLogArchiveMode == ARCHIVE_MODE_OFF || wal_level >= WAL_LEVEL_REPLICA), XLogArchiveMode > ARCHIVE_MODE_OFF)
/* Is WAL archiving enabled always (even during recovery)? */
#define XLogArchivingAlways() \
- (XLogArchiveMode == ARCHIVE_MODE_ALWAYS && wal_level >= WAL_LEVEL_ARCHIVE)
+ (AssertMacro(XLogArchiveMode == ARCHIVE_MODE_OFF || wal_level >= WAL_LEVEL_REPLICA), XLogArchiveMode == ARCHIVE_MODE_ALWAYS)
#define XLogArchiveCommandSet() (XLogArchiveCommand[0] != '\0')
/*
* Is WAL-logging necessary for archival or log-shipping, or can we skip
* WAL-logging if we fsync() the data before committing instead?
*/
-#define XLogIsNeeded() (wal_level >= WAL_LEVEL_ARCHIVE)
+#define XLogIsNeeded() (wal_level >= WAL_LEVEL_REPLICA)
/*
* Is a full-page image needed for hint bit updates?
@@ -153,7 +152,7 @@ extern int wal_level;
#define XLogHintBitIsNeeded() (DataChecksumsEnabled() || wal_log_hints)
/* Do we need to WAL-log information required only for Hot Standby and logical replication? */
-#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_HOT_STANDBY)
+#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_REPLICA)
/* Do we need to WAL-log information required only for logical replication? */
#define XLogLogicalInfoActive() (wal_level >= WAL_LEVEL_LOGICAL)
diff --git a/src/include/catalog/pg_control.h b/src/include/catalog/pg_control.h
index 86fbdce..7ba396d 100644
--- a/src/include/catalog/pg_control.h
+++ b/src/include/catalog/pg_control.h
@@ -54,7 +54,7 @@ typedef struct CheckPoint
/*
* Oldest XID still running. This is only needed to initialize hot standby
* mode from an online checkpoint, so we only bother calculating this for
- * online checkpoints and only when wal_level is hot_standby. Otherwise
+ * online checkpoints and only when wal_level is replica. Otherwise
* it's set to InvalidTransactionId.
*/
TransactionId oldestActiveXid;
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index a8e6f0c..5254235 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -383,7 +383,7 @@ sub init
if ($params{allows_streaming})
{
- print $conf "wal_level = hot_standby\n";
+ print $conf "wal_level = replica\n";
print $conf "max_wal_senders = 5\n";
print $conf "wal_keep_segments = 20\n";
print $conf "max_wal_size = 128MB\n";
--
2.7.2
On Tue, Mar 1, 2016 at 10:02 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 2/8/16 7:34 AM, Michael Paquier wrote:
- if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY) + if (ControlFile->wal_level < WAL_LEVEL_REPLICA) Upthread it was mentioned that switching to an approach where enum values are directly listed would be better. The target of an extra patch on top of this one?I'm not sure what is meant by that.
The following for example, aka using only equal comparators with the
name of wal_level used:
if (ArchiveRecoveryRequested && EnableHotStandby)
{
- if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
+ if (ControlFile->wal_level == WAL_LEVEL_ARCHIVE ||
+ ControlFile->wal_level == WAL_LEVEL_MINIMAL)
ereport(ERROR,
But that's nitpicking (this was mentioned upthread), and not something
this patch should care about.- if (wal_level < WAL_LEVEL_ARCHIVE)
- ereport(ERROR,
-
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
- errmsg("replication slots can only be
used if wal_level >= archive")));
We should still forbid the creation of replication slots if wal_level = minimal.I think I took this out because you actually can't get to that check,
but I put it back in because it seems better for clarity.
It is possible to hit it, take for example the following set of
parameters in postgresql.conf:
max_replication_slots = 3
wal_level = minimal
max_wal_senders = 0
=# select pg_create_physical_replication_slot('toto');
ERROR: 55000: replication slots can only be used if wal_level >= archive
LOCATION: CheckSlotRequirements, slot.c:766
If this patch gets committed before the one improving the checkpoint
skip logic when wal_level >= hot_standby regarding standby snapshots
(/messages/by-id/CAB7nPqQAaB0v25tt4SJ_mGc3aHfZrionEG4E5cceGVZc0B6QyA@mail.gmail.com),
something to not forget is that there will be a regression: on idle
systems checkpoints won't be skipped anymore, which is now what
happens with wal_level = archive on HEAD.
Except this last concern, the patch is in a nice shape, and does what
it says it does.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/8/16 2:34 PM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
On 1/26/16 10:56 AM, Simon Riggs wrote:
Removing one of "archive" or "hot standby" will just cause confusion and
breakage, so neither is a good choice for removal.What we should do is
1. Map "archive" and "hot_standby" to one level with a new name that
indicates that it can be used for both/either backup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed
in a later release.Updated patch to reflect these suggestions.
I wonder if the "keep one / keep both" argument is running in circles as
new reviewers arrive at the thread. Perhaps somebody could read the
whole thread(s) and figure out a way to find consensus so that we move
forward on this.
There was a lot of argument upstream about whether to keep 'hot_standby'
or 'archive' but after the proposal to change it to 'replica' came up
everybody seemed to fall in line with that.
+1 from me for using 'replica' as the WAL level to replace 'hot_standby'
and 'archive'.
+1 from me for removing the 'hot_standby' and 'archive' options entirely
in 9.6 rather than deprecating.
Unless anyone has objections I would like to mark this 'ready for
committer'.
--
-David
david@pgmasters.net
On 3/11/16 1:29 PM, David Steele wrote:
Unless anyone has objections I would like to mark this 'ready for
committer'.
This patch is now ready for committer.
--
-David
david@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Mar 14, 2016 at 12:50 PM, David Steele <david@pgmasters.net> wrote:
On 3/11/16 1:29 PM, David Steele wrote:
Unless anyone has objections I would like to mark this 'ready for
committer'.This patch is now ready for committer.
Yes, thanks, I am cool with this version as well. I guess I should
have done what you just did at my last review to be honest.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Mar 14, 2016 at 11:46 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Mon, Mar 14, 2016 at 12:50 PM, David Steele <david@pgmasters.net> wrote:
On 3/11/16 1:29 PM, David Steele wrote:
Unless anyone has objections I would like to mark this 'ready for
committer'.This patch is now ready for committer.
Yes, thanks, I am cool with this version as well. I guess I should
have done what you just did at my last review to be honest.
This patch has been committed as b555ed8, and maps wal_level =
"archive" to "hot_standby". As mentioned here, the condition to skip
checkpoints when a system is idle is already broken for a couple of
releases when wal_level = "hot_standby":
/messages/by-id/CAB7nPqT5XdZYo0rub8hyBC9CiWxB6=TSG7ffm_QBR+Q4L8ZFGg@mail.gmail.com
So now it is broken as for "archive".
This has been already discussed on this thread:
/messages/by-id/20151016203031.3019.72930@wrigleys.postgresql.org
And there is a patch as well:
https://commitfest.postgresql.org/9/398/
As the bug discussed previously is now also a regression specific to
9.6, are there objections if I add an open item?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers