Index: doc/src/sgml/config.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.280 diff -c -c -r1.280 config.sgml *** doc/src/sgml/config.sgml 31 May 2010 15:50:48 -0000 1.280 --- doc/src/sgml/config.sgml 3 Jun 2010 14:05:21 -0000 *************** *** 1901,1908 **** is zero (the default), the system doesn't keep any extra segments for standby purposes, and the number of old WAL segments available for standbys is determined based only on the location of the previous ! checkpoint and status of WAL archiving. ! This parameter can only be set in the postgresql.conf file or on the server command line. --- 1901,1909 ---- is zero (the default), the system doesn't keep any extra segments for standby purposes, and the number of old WAL segments available for standbys is determined based only on the location of the previous ! checkpoint and status of WAL archiving. To temporarily keep ! all log file segments, use the value -1. This ! parameter can only be set in the postgresql.conf file or on the server command line. Index: doc/src/sgml/high-availability.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/high-availability.sgml,v retrieving revision 1.70 diff -c -c -r1.70 high-availability.sgml *** doc/src/sgml/high-availability.sgml 29 May 2010 09:01:10 -0000 1.70 --- doc/src/sgml/high-availability.sgml 3 Jun 2010 14:05:21 -0000 *************** *** 750,756 **** If you use streaming replication without file-based continuous archiving, you have to set wal_keep_segments in the master to a value high enough to ensure that old WAL segments are not recycled ! too early, while the standby might still need them to catch up. If the standby falls behind too much, it needs to be reinitialized from a new base backup. If you set up a WAL archive that's accessible from the standby, wal_keep_segments is not required as the standby can always --- 750,760 ---- If you use streaming replication without file-based continuous archiving, you have to set wal_keep_segments in the master to a value high enough to ensure that old WAL segments are not recycled ! too early, while the standby might still need them to catch up. This ! is particularly important when performing a base backup because the ! standby will need all WAL segments generated since the start of the ! backup; consider setting wal_keep_segments to ! -1 temporarily in such cases. If the standby falls behind too much, it needs to be reinitialized from a new base backup. If you set up a WAL archive that's accessible from the standby, wal_keep_segments is not required as the standby can always Index: src/backend/access/transam/xlog.c =================================================================== RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v retrieving revision 1.415 diff -c -c -r1.415 xlog.c *** src/backend/access/transam/xlog.c 2 Jun 2010 09:28:44 -0000 1.415 --- src/backend/access/transam/xlog.c 3 Jun 2010 14:05:22 -0000 *************** *** 7337,7343 **** * Delete old log files (those no longer needed even for previous * checkpoint or the standbys in XLOG streaming). */ ! if (_logId || _logSeg) { /* * Calculate the last segment that we need to retain because of --- 7337,7343 ---- * Delete old log files (those no longer needed even for previous * checkpoint or the standbys in XLOG streaming). */ ! if ((_logId || _logSeg) && wal_keep_segments != -1) { /* * Calculate the last segment that we need to retain because of Index: src/backend/utils/misc/guc.c =================================================================== RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v retrieving revision 1.554 diff -c -c -r1.554 guc.c *** src/backend/utils/misc/guc.c 2 May 2010 02:10:33 -0000 1.554 --- src/backend/utils/misc/guc.c 3 Jun 2010 14:05:25 -0000 *************** *** 1661,1667 **** NULL }, &wal_keep_segments, ! 0, 0, INT_MAX, NULL, NULL }, { --- 1661,1667 ---- NULL }, &wal_keep_segments, ! 0, -1, INT_MAX, NULL, NULL }, {