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 files changed, 19 insertions, 1 deletions

diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 1c1e9f17d2..6c41844b5f 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -30,7 +30,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/replication/walsender.c,v 1.17 2010/04/21 00:51:56 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/replication/walsender.c,v 1.18 2010/04/28 16:10:42 heikki Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -253,6 +253,24 @@ WalSndHandshake(void)
 					{
 						StringInfoData buf;
 
+						/*
+						 * Check that we're logging enough information in the
+						 * WAL for log-shipping.
+						 *
+						 * NOTE: This only checks the current value of
+						 * wal_level. Even if the current setting is not
+						 * 'minimal', there can be old WAL in the pg_xlog
+						 * directory that was created with 'minimal'.
+						 * So this is not bulletproof, the purpose is
+						 * just to give a user-friendly error message that
+						 * hints how to configure the system correctly.
+						 */
+						if (wal_level == WAL_LEVEL_MINIMAL)
+							ereport(FATAL,
+									(errcode(ERRCODE_CANNOT_CONNECT_NOW),
+									 errmsg("standby connections not allowed because wal_level='minimal'")));
+
+
 						/* Send a CopyOutResponse message, and start streaming */
 						pq_beginmessage(&buf, 'H');
 						pq_sendbyte(&buf, 0);