Skip to content

Commit 9b8a733

Browse files
hlinnakahlinnaka
committed
Introduce wal_level GUC to explicitly control if information needed for
archival or hot standby should be WAL-logged, instead of deducing that from other options like archive_mode. This replaces recovery_connections GUC in the primary, where it now has no effect, but it's still used in the standby to enable/disable hot standby. Remove the WAL-logging of "unlogged operations", like creating an index without WAL-logging and fsyncing it at the end. Instead, we keep a copy of the wal_mode setting and the settings that affect how much shared memory a hot standby server needs to track master transactions (max_connections, max_prepared_xacts, max_locks_per_xact) in pg_control. Whenever the settings change, at server restart, write a WAL record noting the new settings and update pg_control. This allows us to notice the change in those settings in the standby at the right moment, they used to be included in checkpoint records, but that meant that a changed value was not reflected in the standby until the first checkpoint after the change. Bump PG_CONTROL_VERSION and XLOG_PAGE_MAGIC. Whack XLOG_PAGE_MAGIC back to the sequence it used to follow, before hot standby and subsequent patches changed it to 0x9003.
1 parent a2de482 commit 9b8a733

File tree

22 files changed

+340
-224
lines changed

22 files changed

+340
-224
lines changed

‎doc/src/sgml/backup.sgml

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.152 2010/04/20 00:26:06 rhaas Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.153 2010/04/28 16:10:39 heikki Exp $ -->
22

33
<chapter id="backup">
44
<title>Backup and Restore</title>
@@ -689,8 +689,7 @@ archive_command = 'test ! -f /mnt/server/archivedir/%f &amp;&amp; cp %p /mnt/ser
689689
</para>
690690

691691
<para>
692-
When <varname>archive_mode</> is <literal>off</> and <xref
693-
linkend="guc-max-wal-senders"> is zero some SQL commands
692+
When <varname>wal_level</> is <literal>minimal</> some SQL commands
694693
are optimized to avoid WAL logging, as described in <xref
695694
linkend="populate-pitr">. If archiving or streaming replication were
696695
turned on during execution of one of these statements, WAL would not

‎doc/src/sgml/config.sgml

Lines changed: 51 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.270 2010/04/26 10:51:59 rhaas Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.271 2010/04/28 16:10:39 heikki Exp $ -->
22

33
<chapter Id="runtime-config">
44
<title>Server Configuration</title>
@@ -1353,6 +1353,45 @@ SET ENABLE_SEQSCAN TO OFF;
13531353
<title>Settings</title>
13541354
<variablelist>
13551355

1356+
<varlistentry id="guc-wal-level" xreflabel="wal_level">
1357+
<term><varname>wal_level</varname> (<type>enum</type>)</term>
1358+
<indexterm>
1359+
<primary><varname>wal_level</> configuration parameter</primary>
1360+
</indexterm>
1361+
<listitem>
1362+
<para>
1363+
<varname>wal_level</> determines how much information is written
1364+
to the WAL. The default value is <literal>minimal</>, which writes
1365+
only minimal information needed to recover from a crash or immediate
1366+
shutdown. <literal>archive</> adds logging required for WAL archiving,
1367+
and <literal>hot_standby</> further adds information required to run
1368+
read-only queries on a standby server.
1369+
This parameter can only be set at server start.
1370+
</para>
1371+
<para>
1372+
In <literal>minimal</> level, WAL-logging of some bulk operations, like
1373+
<command>CREATE INDEX</>, <command>CLUSTER</> and <command>COPY</> on
1374+
a table that was created or truncated in the same transaction can be
1375+
safely skipped, which can make those operations much faster (see
1376+
<xref linkend="populate-pitr">). But minimal WAL does not contain
1377+
enough information to reconstruct the data from a base backup and the
1378+
WAL logs, so at least <literal>archive</> level must be used to enable
1379+
WAL archiving (<xref linkend="guc-archive-mode">) and streaming
1380+
replication.
1381+
</para>
1382+
<para>
1383+
In <literal>hot_standby</> level, the same information is logged as
1384+
with <literal>archive</>, plus information needed to reconstruct
1385+
the status of running transactions from the WAL. To enable read-only
1386+
queries on a standby server, <varname>wal_level</> must be set to
1387+
<literal>hot_standby</> on the primary. It is thought that there is
1388+
little measurable difference in performance from using
1389+
<literal>hot_standby</> level over <literal>archive</>, so feedback
1390+
is welcome if any production impacts are noticeable.
1391+
</para>
1392+
</listitem>
1393+
</varlistentry>
1394+
13561395
<varlistentry id="guc-fsync" xreflabel="fsync">
13571396
<indexterm>
13581397
<primary><varname>fsync</> configuration parameter</primary>
@@ -1726,7 +1765,9 @@ SET ENABLE_SEQSCAN TO OFF;
17261765
<varname>archive_mode</> and <varname>archive_command</> are
17271766
separate variables so that <varname>archive_command</> can be
17281767
changed without leaving archiving mode.
1729-
This parameter can only be set at server start.
1768+
This parameter can only be set at server start. <varname>wal_level</>
1769+
must be set to <literal>archive</> or <literal>hot_standby</> to
1770+
enable <varname>archive_mode</>.
17301771
</para>
17311772
</listitem>
17321773
</varlistentry>
@@ -1818,7 +1859,9 @@ SET ENABLE_SEQSCAN TO OFF;
18181859
Specifies the maximum number of concurrent connections from standby
18191860
servers (i.e., the maximum number of simultaneously running WAL sender
18201861
processes). The default is zero. This parameter can only be set at
1821-
server start.
1862+
server start. <varname>wal_level</> must be set to <literal>archive</>
1863+
or <literal>hot_standby</> to allow connections from standby
1864+
connections.
18221865
</para>
18231866
</listitem>
18241867
</varlistentry>
@@ -1884,16 +1927,11 @@ SET ENABLE_SEQSCAN TO OFF;
18841927
</indexterm>
18851928
<listitem>
18861929
<para>
1887-
Parameter has two roles. During recovery, specifies whether or not
1888-
you can connect and run queries to enable <xref linkend="hot-standby">.
1889-
During normal running, specifies whether additional information is written
1890-
to WAL to allow recovery connections on a standby server that reads
1891-
WAL data generated by this server. The default value is
1892-
<literal>on</literal>. It is thought that there is little
1893-
measurable difference in performance from using this feature, so
1894-
feedback is welcome if any production impacts are noticeable.
1895-
It is likely that this parameter will be removed in later releases.
1896-
This parameter can only be set at server start.
1930+
Specifies whether or not you can connect and run queries during
1931+
recovery, for <xref linkend="hot-standby">. The default value is
1932+
<literal>on</literal>.
1933+
This parameter can only be set at server start. It only has effect
1934+
during archive recovery or in standby mode.
18971935
</para>
18981936
</listitem>
18991937
</varlistentry>

‎doc/src/sgml/high-availability.sgml

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.63 2010/04/26 19:09:25 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.64 2010/04/28 16:10:40 heikki Exp $ -->
22

33
<chapter id="high-availability">
44
<title>High Availability, Load Balancing, and Replication</title>
@@ -1593,9 +1593,9 @@ LOG: database system is ready to accept read only connections
15931593
</programlisting>
15941594

15951595
Consistency information is recorded once per checkpoint on the primary, as long
1596-
as <varname>recovery_connections</> is enabled on the primary. It is not possible
1596+
as <varname>wal_level</> is set to <literal>hot_standby</> on the primary. It is not possible
15971597
to enable recovery connections on the standby when reading WAL written during the
1598-
period that <varname>recovery_connections</> was disabled on the primary.
1598+
period that <varname>wal_level</> was not set to <literal>hot_standby</> on the primary.
15991599
Reaching a consistent state can also be delayed in the presence
16001600
of both of these conditions:
16011601

@@ -1842,7 +1842,7 @@ LOG: database system is ready to accept read only connections
18421842
</para>
18431843

18441844
<para>
1845-
On the primary, parameters <varname>recovery_connections</> and
1845+
On the primary, parameters <varname>wal_level</> and
18461846
<varname>vacuum_defer_cleanup_age</> can be used.
18471847
<varname>max_standby_delay</> has no effect if set on the primary.
18481848
</para>

‎doc/src/sgml/perform.sgml

Lines changed: 22 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.76 2010/04/20 00:26:06 rhaas Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.77 2010/04/28 16:10:40 heikki Exp $ -->
22

33
<chapter id="performance-tips">
44
<title>Performance Tips</title>
@@ -835,10 +835,9 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
835835
<command>TRUNCATE</command> command. In such cases no WAL
836836
needs to be written, because in case of an error, the files
837837
containing the newly loaded data will be removed anyway.
838-
However, this consideration does not apply when
839-
<xref linkend="guc-archive-mode"> is on or streaming replication
840-
is allowed (i.e., <xref linkend="guc-max-wal-senders"> is more
841-
than or equal to one), as all commands must write WAL in that case.
838+
However, this consideration only applies when
839+
<xref linkend="guc-wal-level"> is <literal>minimal</> as all commands
840+
must write WAL otherwise.
842841
</para>
843842

844843
</sect2>
@@ -910,29 +909,27 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
910909
</sect2>
911910

912911
<sect2 id="populate-pitr">
913-
<title>Turn off <varname>archive_mode</varname> and streaming replication</title>
912+
<title>Disable WAL archival and streaming replication</title>
914913

915914
<para>
916915
When loading large amounts of data into an installation that uses
917-
WAL archiving or streaming replication, you might want to disable
918-
archiving (turn off the <xref linkend="guc-archive-mode">
919-
configuration variable) and replication (zero the
920-
<xref linkend="guc-max-wal-senders"> configuration variable)
921-
while loading. It might be
922-
faster to take a new base backup after the load has completed
923-
than to process a large amount of incremental WAL data.
924-
But note that changing either of these variables requires
925-
a server restart.
916+
WAL archiving or streaming replication, it might be faster to take a
917+
new base backup after the load has completed than to process a large
918+
amount of incremental WAL data. You might want to disable archiving
919+
and streaming replication while loading, by setting
920+
<xref linkend="guc-wal-level"> to <literal>minimal</>,
921+
<xref linkend="guc-archive-mode"> <literal>off</>, and
922+
<xref linkend="guc-max-wal-senders"> to zero).
923+
But note that changing these settings requires a server restart.
926924
</para>
927925

928926
<para>
929927
Aside from avoiding the time for the archiver or WAL sender to
930928
process the WAL data,
931929
doing this will actually make certain commands faster, because they
932-
are designed not to write WAL at all if <varname>archive_mode</varname>
933-
is off and <varname>max_wal_senders</varname> is zero. (They can
934-
guarantee crash safety more cheaply by doing an
935-
<function>fsync</> at the end than by writing WAL.)
930+
are designed not to write WAL at all if <varname>wal_level</varname>
931+
is <literal>minimal</>. (They can guarantee crash safety more cheaply
932+
by doing an <function>fsync</> at the end than by writing WAL.)
936933
This applies to the following commands:
937934
<itemizedlist>
938935
<listitem>
@@ -1014,10 +1011,12 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
10141011
</listitem>
10151012
<listitem>
10161013
<para>
1017-
If using WAL archiving, consider disabling it during the restore.
1018-
To do that, turn off <varname>archive_mode</varname> before loading the
1019-
dump script, and afterwards turn it back on
1020-
and take a fresh base backup.
1014+
If using WAL archiving or streaming replication, consider disabling
1015+
them during the restore. To do that, set <varname>arcive_mode</> off,
1016+
<varname>wal_level</varname> to <literal>minimal</>, and
1017+
<varname>max_wal_senders</> zero before loading the dump script,
1018+
and afterwards set them back to the right values and take a fresh
1019+
base backup.
10211020
</para>
10221021
</listitem>
10231022
<listitem>

‎src/backend/access/heap/rewriteheap.c

Lines changed: 1 addition & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -96,7 +96,7 @@
9696
* Portions Copyright (c) 1994-5, Regents of the University of California
9797
*
9898
* IDENTIFICATION
99-
* $PostgreSQL: pgsql/src/backend/access/heap/rewriteheap.c,v 1.21 2010/02/26 02:00:33 momjian Exp $
99+
* $PostgreSQL: pgsql/src/backend/access/heap/rewriteheap.c,v 1.22 2010/04/28 16:10:40 heikki Exp $
100100
*
101101
*-------------------------------------------------------------------------
102102
*/
@@ -278,16 +278,6 @@ end_heap_rewrite(RewriteState state)
278278
(char *) state->rs_buffer, true);
279279
}
280280

281-
/* Write an XLOG UNLOGGED record if WAL-logging was skipped */
282-
if (!state->rs_use_wal && !state->rs_new_rel->rd_istemp)
283-
{
284-
char reason[NAMEDATALEN + 30];
285-
286-
snprintf(reason, sizeof(reason), "heap rewrite on \"%s\"",
287-
RelationGetRelationName(state->rs_new_rel));
288-
XLogReportUnloggedStatement(reason);
289-
}
290-
291281
/*
292282
* If the rel isn't temp, must fsync before commit. We use heap_sync to
293283
* ensure that the toast table gets fsync'd too.

‎src/backend/access/nbtree/nbtsort.c

Lines changed: 1 addition & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -59,7 +59,7 @@
5959
* Portions Copyright (c) 1994, Regents of the University of California
6060
*
6161
* IDENTIFICATION
62-
* $PostgreSQL: pgsql/src/backend/access/nbtree/nbtsort.c,v 1.124 2010/02/26 02:00:34 momjian Exp $
62+
* $PostgreSQL: pgsql/src/backend/access/nbtree/nbtsort.c,v 1.125 2010/04/28 16:10:40 heikki Exp $
6363
*
6464
*-------------------------------------------------------------------------
6565
*/
@@ -215,19 +215,6 @@ _bt_leafbuild(BTSpool *btspool, BTSpool *btspool2)
215215
*/
216216
wstate.btws_use_wal = XLogIsNeeded() && !wstate.index->rd_istemp;
217217

218-
/*
219-
* Write an XLOG UNLOGGED record if WAL-logging was skipped because WAL
220-
* archiving is not enabled.
221-
*/
222-
if (!wstate.btws_use_wal && !wstate.index->rd_istemp)
223-
{
224-
char reason[NAMEDATALEN + 20];
225-
226-
snprintf(reason, sizeof(reason), "b-tree build on \"%s\"",
227-
RelationGetRelationName(wstate.index));
228-
XLogReportUnloggedStatement(reason);
229-
}
230-
231218
/* reserve the metapage */
232219
wstate.btws_pages_alloced = BTREE_METAPAGE + 1;
233220
wstate.btws_pages_written = 0;

0 commit comments

Comments
 (0)