Index: doc/src/sgml/backup.sgml =================================================================== RCS file: /projects/cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.69 diff -c -c -r2.69 backup.sgml *** doc/src/sgml/backup.sgml 25 Jun 2005 22:47:28 -0000 2.69 --- doc/src/sgml/backup.sgml 2 Oct 2005 22:27:47 -0000 *************** *** 1147,1159 **** ! It should also be noted that the present WAL ! format is extremely bulky since it includes many disk page ! snapshots. This is appropriate for crash recovery purposes, since we may need to fix partially-written disk pages. It is not ! necessary to store so many page copies for PITR operations, however. An area for future development is to compress archived WAL data by ! removing unnecessary page copies. In the meantime, administrators may wish to reduce the number of page snapshots included in WAL by increasing the checkpoint interval parameters as much as feasible. --- 1147,1168 ---- ! It should also be noted that the default WAL ! format is fairly bulky since it includes many disk page snapshots. The pages ! are partially compressed, using the simple expedient of removing the ! empty space (if any) within each block. You can significantly reduce ! the total volume of archived logs by turning off page snapshots ! using the parameter, ! though you should read the notes and warnings in ! before you do so. ! These page snapshots are designed to allow crash recovery, since we may need to fix partially-written disk pages. It is not ! necessary to store these page copies for PITR operations, however. ! If you turn off , your PITR ! backup and recovery operations will continue to work successfully. An area for future development is to compress archived WAL data by ! removing unnecessary page copies when ! is turned on. In the meantime, administrators may wish to reduce the number of page snapshots included in WAL by increasing the checkpoint interval parameters as much as feasible. Index: doc/src/sgml/config.sgml =================================================================== RCS file: /projects/cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.23 diff -c -c -r1.23 config.sgml *** doc/src/sgml/config.sgml 24 Sep 2005 23:25:31 -0000 1.23 --- doc/src/sgml/config.sgml 2 Oct 2005 22:27:49 -0000 *************** *** 1360,1366 **** When this option is on, the PostgreSQL server writes full pages to WAL when they are first modified after a ! checkpoint so full recovery is possible. Turning this option off might lead to a corrupt system after an operating system crash or power failure because uncorrected partial pages might contain inconsistent or corrupt data. The risks are less but similar to --- 1360,1366 ---- When this option is on, the PostgreSQL server writes full pages to WAL when they are first modified after a ! checkpoint so crash recovery is possible. Turning this option off might lead to a corrupt system after an operating system crash or power failure because uncorrected partial pages might contain inconsistent or corrupt data. The risks are less but similar to Index: doc/src/sgml/wal.sgml =================================================================== RCS file: /projects/cvsroot/pgsql/doc/src/sgml/wal.sgml,v retrieving revision 1.35 diff -c -c -r1.35 wal.sgml *** doc/src/sgml/wal.sgml 1 Oct 2005 01:42:43 -0000 1.35 --- doc/src/sgml/wal.sgml 2 Oct 2005 22:27:50 -0000 *************** *** 12,18 **** failure (unrelated to the non-volatile area itself). To accomplish this, PostgreSQL uses the magnetic platters of modern disk drives for permanent storage that is immune to the failures ! listed above. In fact, a computer can be completely destroyed, but if the disk drives survive they can be moved to another computer with similar hardware and all committed transactions will remain intact. --- 12,18 ---- failure (unrelated to the non-volatile area itself). To accomplish this, PostgreSQL uses the magnetic platters of modern disk drives for permanent storage that is immune to the failures ! listed above. In fact, even if a computer is fatally damaged, if the disk drives survive they can be moved to another computer with similar hardware and all committed transactions will remain intact. *************** *** 68,78 **** these partially written cases. To guard against that, PostgreSQL periodically writes full page images to permanent storage before modifying the actual page on ! disk. By doing this, during recovery PostgreSQL can restore partially-written pages. If you have a battery-backed disk ! controller that prevents partial page writes, you can turn off this ! page imaging by using the ! parameter. --- 68,80 ---- these partially written cases. To guard against that, PostgreSQL periodically writes full page images to permanent storage before modifying the actual page on ! disk. By doing this, during crash recovery PostgreSQL can restore partially-written pages. If you have a battery-backed disk ! controller or filesystem (e.g. Reiser4) that prevents partial page writes, ! you can turn off this page imaging by using the ! parameter. This parameter has no ! effect on the successful use of Point in Time Recovery (PITR), ! described in . *************** *** 107,120 **** the data pages can be redone from the log records. (This is roll-forward recovery, also known as REDO.) - - - - Benefits of Write-Ahead Logging ! ! fsync ! The first major benefit of using WAL is a --- 109,118 ---- the data pages can be redone from the log records. (This is roll-forward recovery, also known as REDO.) ! ! WAL brings three major benefits: ! The first major benefit of using WAL is a *************** *** 131,141 **** ! The next benefit is consistency of the data pages. The truth is ! that, before WAL, PostgreSQL was never able to guarantee ! consistency in the case of a crash. Before ! WAL, any crash during writing could result in: --- 129,139 ---- ! The next benefit is crash recovery protection. The truth is ! that, before WAL was introduced back in release 7.1, PostgreSQL was never able to guarantee ! consistency in the case of a crash. Now, ! WAL protects fully against the following problems: *************** *** 151,163 **** of partially written data pages - - Problems with indexes (problems 1 and 2) could possibly have been - fixed by additional fsync calls, but it is - not obvious how to handle the last case without - WAL. WAL saves the entire data - page content in the log if that is required to ensure page - consistency for after-crash recovery. --- 149,154 ---- *************** *** 214,225 **** checkpoint_timeout causes checkpoints to be done more often. This allows faster after-crash recovery (since less work will need to be redone). However, one must balance this against the ! increased cost of flushing dirty data pages more often. In addition, ! to ensure data page consistency, the first modification of a data ! page after each checkpoint results in logging the entire page ! content. Thus a smaller checkpoint interval increases the volume of ! output to the WAL log, partially negating the goal of using a smaller ! interval, and in any case causing more disk I/O. --- 205,218 ---- checkpoint_timeout causes checkpoints to be done more often. This allows faster after-crash recovery (since less work will need to be redone). However, one must balance this against the ! increased cost of flushing dirty data pages more often. If ! is set (the default), there is ! another factor to consider. To ensure data page consistency, ! the first modification of a data page after each checkpoint results in ! logging the entire page content. In that case, ! a smaller checkpoint interval increases the volume of output to the WAL log, ! partially negating the goal of using a smaller interval, ! and in any case causing more disk I/O. *************** *** 234,240 **** a message will be output to the server log recommending increasing checkpoint_segments. Occasional appearance of such a message is not cause for alarm, but if it appears often then the ! checkpoint control parameters should be increased. --- 227,235 ---- a message will be output to the server log recommending increasing checkpoint_segments. Occasional appearance of such a message is not cause for alarm, but if it appears often then the ! checkpoint control parameters should be increased. Bulk operations such ! as a COPY, INSERT SELECT etc. may cause a number of such warnings if you ! do not set high enough. *************** *** 252,258 **** ! There are two commonly used WAL functions: LogInsert and LogFlush. LogInsert is used to place a new record into the WAL buffers in shared memory. If there is no --- 247,253 ---- ! There are two commonly used internal WAL functions: LogInsert and LogFlush. LogInsert is used to place a new record into the WAL buffers in shared memory. If there is no *************** *** 275,283 **** modifying the configuration parameter . The default number of WAL buffers is 8. Increasing this value will ! correspondingly increase shared memory usage. (It should be noted ! that there is presently little evidence to suggest that increasing ! wal_buffers beyond the default is worthwhile.) --- 270,280 ---- modifying the configuration parameter . The default number of WAL buffers is 8. Increasing this value will ! correspondingly increase shared memory usage. When ! is set and the system is very busy, ! setting this value higher will help smooth response times during the ! period immediately following each checkpoint. As a guide, a setting of 1024 ! would be considered to be high. *************** *** 313,319 **** (provided that PostgreSQL has been compiled with support for it) will result in each LogInsert and LogFlush ! WAL call being logged to the server log. This option may be replaced by a more general mechanism in the future. --- 310,317 ---- (provided that PostgreSQL has been compiled with support for it) will result in each LogInsert and LogFlush ! WAL call being logged to the server log. The output ! is too verbose for use as a guide to performance tuning. This option may be replaced by a more general mechanism in the future.