diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 93c9ff183c..c84529f267 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1,4 +1,4 @@ - + Server Configuration @@ -1352,7 +1352,7 @@ SET ENABLE_SEQSCAN TO OFF; Settings - + wal_level (enum) @@ -1362,7 +1362,7 @@ SET ENABLE_SEQSCAN TO OFF; wal_level determines how much information is written to the WAL. The default value is minimal, which writes - only minimal information needed to recover from a crash or immediate + only the information needed to recover from a crash or immediate shutdown. archive adds logging required for WAL archiving, and hot_standby further adds information required to run read-only queries on a standby server. @@ -1385,8 +1385,8 @@ SET ENABLE_SEQSCAN TO OFF; the status of running transactions from the WAL. To enable read-only queries on a standby server, wal_level must be set to hot_standby on the primary. It is thought that there is - little measurable difference in performance from using - hot_standby level over archive, so feedback + little measurable difference in performance between using + hot_standby and archive levels, so feedback is welcome if any production impacts are noticeable. @@ -1836,7 +1836,7 @@ SET ENABLE_SEQSCAN TO OFF; - + @@ -1860,8 +1860,7 @@ SET ENABLE_SEQSCAN TO OFF; servers (i.e., the maximum number of simultaneously running WAL sender processes). The default is zero. This parameter can only be set at server start. wal_level must be set to archive - or hot_standby to allow connections from standby - connections. + or hot_standby to allow connections from standby servers. @@ -1873,7 +1872,7 @@ SET ENABLE_SEQSCAN TO OFF; Specifies the delay between activity rounds for the WAL sender. - In each round the WAL sender sends any WAL accumulated since last + In each round the WAL sender sends any WAL accumulated since the last round to the standby server. It then sleeps for wal_sender_delay milliseconds, and repeats. The default value is 200 milliseconds (200ms). @@ -1893,14 +1892,17 @@ SET ENABLE_SEQSCAN TO OFF; - Specifies the number of log file segments kept in pg_xlog - directory, in case a standby server needs to fetch them via streaming + Specifies the number of past log file segments kept in the + pg_xlog + directory, in case a standby server needs to fetch them for streaming replication. Each segment is normally 16 megabytes. If a standby - server connected to the primary falls behind more than + server connected to the primary falls behind by more than wal_keep_segments segments, the primary might remove - a WAL segment still needed by the standby and the replication - connection will be terminated. + a WAL segment still needed by the standby, in which case the + replication connection will be terminated. + + This sets only the minimum number of segments retained for standby purposes; the system might need to retain more segments for WAL archival or to recover from a checkpoint. If wal_keep_segments @@ -1920,43 +1922,44 @@ SET ENABLE_SEQSCAN TO OFF; - - recovery_connections (boolean) + + hot_standby (boolean) - recovery_connections configuration parameter + hot_standby configuration parameter Specifies whether or not you can connect and run queries during - recovery, for . The default value is - on. + recovery, as described in . + The default value is off. This parameter can only be set at server start. It only has effect during archive recovery or in standby mode. - - max_standby_delay (string) + + max_standby_delay (integer) max_standby_delay configuration parameter - When server acts as a standby, this parameter specifies a wait policy + When Hot Standby is active, this parameter specifies a wait policy for applying WAL entries that conflict with active queries. If a conflict should occur the server will delay up to this number of seconds before it cancels conflicting queries, as described in . Typically, this parameter is used only during replication. + The value is specified in seconds, and -1 causes the standby to wait + forever for a conflicting query to complete. The default is 30 seconds. This parameter can only be set in the postgresql.conf file or on the server command line. - A high value makes query cancel less likely, and -1 - causes the standby to wait forever for a conflicting query to - complete. Increasing this parameter might delay master server + A high value makes query cancel less likely. + Increasing this parameter or setting it to -1 might delay master server changes from appearing on the standby. @@ -1966,7 +1969,7 @@ SET ENABLE_SEQSCAN TO OFF; query ends, there is a finite time required to apply backlogged WAL logs. If a second long-running query appears before the WAL has caught up, the snapshot taken by the second query will - allow significantly less than max_standby_delay + allow significantly less than max_standby_delay seconds before query cancellation is possible. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index da0d4d5de5..b2f1a583fc 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1,4 +1,4 @@ - + High Availability, Load Balancing, and Replication @@ -1127,7 +1127,8 @@ if (!triggered) Hot Standby is the term used to describe the ability to connect to - the server and run queries while the server is in archive recovery. This + the server and run read-only queries while the server is in archive + recovery. This is useful for both log shipping replication and for restoring a backup to an exact state with great precision. The term Hot Standby also refers to the ability of the server to move @@ -1137,7 +1138,7 @@ if (!triggered) Running queries in recovery mode is similar to normal query operation, - though there are a several usage and administrative differences + though there are several usage and administrative differences noted below. @@ -1573,14 +1574,15 @@ if (!triggered) Administrator's Overview - If there is a recovery.conf file present, the server will start - in Hot Standby mode by default, though recovery_connections can - be disabled via postgresql.conf. The server might take - some time to enable recovery connections since the server must first complete + If hot_standby is turned on in + postgresql.conf and there is a recovery.conf + file present, the server will run in Hot Standby mode. + However, it may take some time for Hot Standby connections to be allowed, + because the server will not accept connections until it has completed sufficient recovery to provide a consistent state against which queries - can run before enabling read only connections. During this period, + can run. During this period, clients that attempt to connect will be refused with an error message. - To confirm the server has come up, either loop retrying to connect from + To confirm the server has come up, either loop trying to connect from the application, or look for these messages in the server logs: @@ -1592,12 +1594,11 @@ LOG: consistent recovery state reached LOG: database system is ready to accept read only connections - Consistency information is recorded once per checkpoint on the primary, as long - as wal_level is set to hot_standby on the primary. It is not possible - to enable recovery connections on the standby when reading WAL written during the - period that wal_level was not set to hot_standby on the primary. - Reaching a consistent state can also be delayed in the presence - of both of these conditions: + 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 wal_level was not set to + hot_standby on the primary. Reaching a consistent state can + also be delayed in the presence of both of these conditions: @@ -1622,10 +1623,9 @@ LOG: database system is ready to accept read only connections if they have been changed on the primary. For these parameters, the value on the standby must be equal to or greater than the value on the primary. If these parameters - are not set high enough then the standby will not be able to process - recovering transactions properly. If these values are set too low - the server will halt. Higher values can then be supplied and the server - restarted to begin recovery again. The parameters are: + are not set high enough then the standby will refuse to start. + Higher values can then be supplied and the server + restarted to begin recovery again. These parameters are: @@ -1648,7 +1648,8 @@ LOG: database system is ready to accept read only connections It is important that the administrator consider the appropriate setting - of max_standby_delay, set in postgresql.conf. + of max_standby_delay, + which can be set in postgresql.conf. There is no optimal setting, so it should be set according to business priorities. For example if the server is primarily tasked as a High Availability server, then you may wish to lower @@ -1657,7 +1658,7 @@ LOG: database system is ready to accept read only connections server for decision support queries then it might be acceptable to set this to a value of many hours (in seconds). It is also possible to set max_standby_delay to -1 which means wait forever for queries - to complete, if there are conflicts; this will be useful when performing + to complete; this will be useful when performing an archive recovery from a backup. @@ -1668,10 +1669,8 @@ LOG: database system is ready to accept read only connections all users are read-only; no changes occur to the data values themselves. Users will still write large sort temporary files and re-generate relcache info files, so no part of the database - is truly read-only during hot standby mode. There is no restriction - on the use of set returning functions, or other users of - tuplestore/tuplesort - code. Note also that writes to remote databases will still be possible, + is truly read-only during hot standby mode. + Note also that writes to remote databases will still be possible, even though the transaction is read-only locally. @@ -1837,20 +1836,22 @@ LOG: database system is ready to accept read only connections Hot Standby Parameter Reference - Various parameters have been mentioned above in + Various parameters have been mentioned above in + and . - On the primary, parameters wal_level and - vacuum_defer_cleanup_age can be used. - max_standby_delay has no effect if set on the primary. + On the primary, parameters and + can be used. + has no effect if set on the primary. - On the standby, parameters recovery_connections and - max_standby_delay can be used. - vacuum_defer_cleanup_age has no effect during recovery. + On the standby, parameters and + can be used. + has no effect during + recovery. @@ -1880,7 +1881,7 @@ LOG: database system is ready to accept read only connections - Valid starting points for recovery connections are generated at each + Valid starting points for standby queries are generated at each checkpoint on the master. If the standby is shut down while the master is in a shutdown state, it might not be possible to re-enter Hot Standby until the primary is started up, so that it generates further starting @@ -1901,7 +1902,7 @@ LOG: database system is ready to accept read only connections that normally take AccessExclusiveLocks, or you plan on having one large transaction that takes many AccessExclusiveLocks, you are advised to select a larger value of max_locks_per_transaction, - up to, but never more than twice the value of the parameter setting on + perhaps as much as twice the value of the parameter on the primary server. You need not consider this at all if your setting of max_prepared_transactions is 0. diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 2d3dab39fe..95c3c3a7d0 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -7,7 +7,7 @@ * Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.405 2010/04/28 16:10:40 heikki Exp $ + * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.406 2010/04/29 21:36:19 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -71,7 +71,7 @@ int XLOGbuffers = 8; int XLogArchiveTimeout = 0; bool XLogArchiveMode = false; char *XLogArchiveCommand = NULL; -bool XLogRequestRecoveryConnections = true; +bool EnableHotStandby = false; int MaxStandbyDelay = 30; bool fullPageWrites = true; bool log_checkpoints = false; @@ -5571,15 +5571,16 @@ GetLatestXLogTime(void) * translation */ #define RecoveryRequiresIntParameter(param_name, currValue, minValue) \ -{ \ +do { \ if (currValue < minValue) \ ereport(ERROR, \ - (errmsg("recovery connections cannot continue because " \ - "%s = %u is a lower setting than on WAL source server (value was %u)", \ - param_name, \ - currValue, \ - minValue))); \ -} + (errmsg("hot standby is not possible because " \ + "%s = %d is a lower setting than on the master server " \ + "(its value was %d)", \ + param_name, \ + currValue, \ + minValue))); \ +} while(0) /* * Check to see if required parameters are set high enough on this server @@ -5595,27 +5596,31 @@ CheckRequiredParameterValues(void) if (InArchiveRecovery && ControlFile->wal_level == WAL_LEVEL_MINIMAL) { ereport(WARNING, - (errmsg("WAL was generated with wal_level='minimal', data may be missing"), - errhint("This happens if you temporarily set wal_level='minimal' without taking a new base backup."))); + (errmsg("WAL was generated with wal_level=\"minimal\", data may be missing"), + errhint("This happens if you temporarily set wal_level=\"minimal\" without taking a new base backup."))); } /* * For Hot Standby, the WAL must be generated with 'hot_standby' mode, * and we must have at least as many backend slots as the primary. */ - if (InArchiveRecovery && XLogRequestRecoveryConnections) + if (InArchiveRecovery && EnableHotStandby) { if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY) ereport(ERROR, - (errmsg("recovery connections cannot start because wal_level was not set to 'hot_standby' on the WAL source server"))); + (errmsg("hot standby is not possible because wal_level was not set to \"hot_standby\" on the master server"), + errhint("Either set wal_level to \"hot_standby\" on the master, or turn off hot_standby here."))); /* We ignore autovacuum_max_workers when we make this test. */ RecoveryRequiresIntParameter("max_connections", - MaxConnections, ControlFile->MaxConnections); + MaxConnections, + ControlFile->MaxConnections); RecoveryRequiresIntParameter("max_prepared_xacts", - max_prepared_xacts, ControlFile->max_prepared_xacts); + max_prepared_xacts, + ControlFile->max_prepared_xacts); RecoveryRequiresIntParameter("max_locks_per_xact", - max_locks_per_xact, ControlFile->max_locks_per_xact); + max_locks_per_xact, + ControlFile->max_locks_per_xact); } } @@ -5953,18 +5958,18 @@ StartupXLOG(void) CheckRequiredParameterValues(); /* - * Initialize recovery connections, if enabled. We won't let backends + * Initialize for Hot Standby, if enabled. We won't let backends * in yet, not until we've reached the min recovery point specified in * control file and we've established a recovery snapshot from a * running-xacts WAL record. */ - if (InArchiveRecovery && XLogRequestRecoveryConnections) + if (InArchiveRecovery && EnableHotStandby) { TransactionId *xids; int nxids; ereport(DEBUG1, - (errmsg("initializing recovery connections"))); + (errmsg("initializing for hot standby"))); InitRecoveryTransactionEnvironment(); @@ -9055,13 +9060,17 @@ StartupProcessMain(void) #endif /* - * Properly accept or ignore signals the postmaster might send us + * Properly accept or ignore signals the postmaster might send us. + * + * Note: ideally we'd not enable handle_standby_sig_alarm unless actually + * doing hot standby, but we don't know that yet. Rely on it to not do + * anything if it shouldn't. */ pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config file */ pqsignal(SIGINT, SIG_IGN); /* ignore query cancel */ pqsignal(SIGTERM, StartupProcShutdownHandler); /* request shutdown */ pqsignal(SIGQUIT, startupproc_quickdie); /* hard crash time */ - if (XLogRequestRecoveryConnections) + if (EnableHotStandby) pqsignal(SIGALRM, handle_standby_sig_alarm); /* ignored unless * InHotStandby */ else diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c index 3564cd5ab3..4fc1fc430b 100644 --- a/src/backend/storage/ipc/procarray.c +++ b/src/backend/storage/ipc/procarray.c @@ -37,7 +37,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/storage/ipc/procarray.c,v 1.67 2010/04/28 00:09:05 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/storage/ipc/procarray.c,v 1.68 2010/04/29 21:36:19 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -179,18 +179,22 @@ ProcArrayShmemSize(void) size = add_size(size, mul_size(sizeof(PGPROC *), PROCARRAY_MAXPROCS)); /* - * During recovery processing we have a data structure called + * During Hot Standby processing we have a data structure called * KnownAssignedXids, created in shared memory. Local data structures are * also created in various backends during GetSnapshotData(), * TransactionIdIsInProgress() and GetRunningTransactionData(). All of the * main structures created in those functions must be identically sized, * since we may at times copy the whole of the data structures around. We * refer to this size as TOTAL_MAX_CACHED_SUBXIDS. + * + * Ideally we'd only create this structure if we were actually doing + * hot standby in the current run, but we don't know that yet at the + * time shared memory is being set up. */ #define TOTAL_MAX_CACHED_SUBXIDS \ ((PGPROC_MAX_CACHED_SUBXIDS + 1) * PROCARRAY_MAXPROCS) - if (XLogRequestRecoveryConnections) + if (EnableHotStandby) { size = add_size(size, mul_size(sizeof(TransactionId), @@ -234,7 +238,7 @@ CreateSharedProcArray(void) } /* Create or attach to the KnownAssignedXids arrays too, if needed */ - if (XLogRequestRecoveryConnections) + if (EnableHotStandby) { KnownAssignedXids = (TransactionId *) ShmemInitStruct("KnownAssignedXids", diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index 2404da8441..d913137b49 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -10,7 +10,7 @@ * Written by Peter Eisentraut . * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.552 2010/04/28 16:10:42 heikki Exp $ + * $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.553 2010/04/29 21:36:19 tgl Exp $ * *-------------------------------------------------------------------- */ @@ -1222,14 +1222,12 @@ static struct config_bool ConfigureNamesBool[] = }, { - {"recovery_connections", PGC_POSTMASTER, WAL_SETTINGS, - gettext_noop("During recovery, allows connections and queries. " - " During normal running, causes additional info to be written" - " to WAL to enable hot standby mode on WAL standby nodes."), + {"hot_standby", PGC_POSTMASTER, WAL_SETTINGS, + gettext_noop("Allows connections and queries during recovery."), NULL }, - &XLogRequestRecoveryConnections, - true, NULL, NULL + &EnableHotStandby, + false, NULL, NULL }, { diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index 5749711568..2ed84127f7 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -185,10 +185,10 @@ # - Hot Standby - -#recovery_connections = on # allows connections during recovery -#max_standby_delay = 30s # max acceptable standby lag (s) to allow queries - # to complete without conflict; -1 disables -#vacuum_defer_cleanup_age = 0 # num transactions by which cleanup is deferred +#hot_standby = off # allows queries during recovery +#max_standby_delay = 30s # max acceptable lag (s) to allow queries to + # complete without conflict; -1 means forever +#vacuum_defer_cleanup_age = 0 # num transactions by which cleanup is deferred # - Replication - diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h index 6936a2a579..7dfe03b4be 100644 --- a/src/include/access/xlog.h +++ b/src/include/access/xlog.h @@ -6,7 +6,7 @@ * Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/include/access/xlog.h,v 1.110 2010/04/28 16:10:43 heikki Exp $ + * $PostgreSQL: pgsql/src/include/access/xlog.h,v 1.111 2010/04/29 21:36:19 tgl Exp $ */ #ifndef XLOG_H #define XLOG_H @@ -189,12 +189,13 @@ extern XLogRecPtr XactLastRecEnd; extern int CheckPointSegments; extern int wal_keep_segments; extern int XLOGbuffers; +extern int XLogArchiveTimeout; extern bool XLogArchiveMode; extern char *XLogArchiveCommand; -extern int XLogArchiveTimeout; -extern bool log_checkpoints; -extern bool XLogRequestRecoveryConnections; +extern bool EnableHotStandby; extern int MaxStandbyDelay; +extern bool log_checkpoints; + /* WAL levels */ typedef enum WalLevel {