From 81fd7532a973fd667ac3e104464884a6ce4b47e8 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Sun, 16 Jul 2000 14:47:57 +0000 Subject: [PATCH] Incorporate README.fsync into main documentation body --- doc/README.fsync | 34 --------------------------------- doc/src/sgml/runtime.sgml | 40 +++++++++++++++++++++++++++++++++------ 2 files changed, 34 insertions(+), 40 deletions(-) delete mode 100644 doc/README.fsync diff --git a/doc/README.fsync b/doc/README.fsync deleted file mode 100644 index ff9adc62f4..0000000000 --- a/doc/README.fsync +++ /dev/null @@ -1,34 +0,0 @@ -Fsync() patch (backend -F option) -================================= - -Normally, the Postgres'95 backend makes sure that updates are actually -committed to disk by calling the standard function fsync() in -several places. Fsync() should guarantee that every modification to -a certain file is actually written to disk and will not hang around -in write caches anymore. This increases the chance that a database -will still be usable after a system crash by a large amount. - -However, this operation severely slows down Postgres'95, because at all -those points it has to wait for the OS to flush the buffers. Especially -in one-shot operations, like creating a new database or loading lots -of data, you'll have a clear restart point if something goes wrong. That's -where the -F option kicks in: it simply disables the calls to fsync(). - -Without fsync(), the OS is allowed to do its best in buffering, sorting -and delaying writes, so this can be a _very_ big perfomance increase. However, -if the system crashes, large parts of the latest transactions will still hang -around in memory without having been committed to disk - lossage of data -is therefore almost certain to occur. - -So it's a tradeoff between data integrity and speed. When initializing a -database, I'd use it - if the machine crashes, you simply remove the files -created and redo the operation. The same goes for bulk-loading data: on -a crash, you remove the database and restore the backup you made before -starting the bulk-load (you always make backups before bulk-loading, -don't you?). - -Whether you want to use it in production, is up to you. If you trust your -operating system, your utility company, and your hardware, you might enable -it; however, keep in mind that you're running in an unsecure mode and that -performance gains will very much depend on access patterns (because it won't -help on reading data). I'd recommend against it. diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index cc6900ece4..addfc54456 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,5 +1,5 @@ @@ -846,11 +846,39 @@ env PGOPTIONS='--geqo=off' psql FSYNC (boolean) - When this is on (default), an fsync() - call is done after each transaction. Turning this off - increases performance but an operating system crash or power - outage might cause data corruption. (Note that a crash of - Postgres itself is not affected.) + If this is option is on, the Postgres backend + will use the fsync() system call in several + places to make sure that updates are physically written to + disk and will not hang around in the write caches. This + increases the chance that a database installation will still + be usable after a operating system or hardware crashes by a + large amount. (Crashes of the database server itself do + not affect this consideration.) + + + + However, this operation severely slows down + Postgres, because at all those points it has + to block and wait for the operating system to flush the + buffers. Without fsync, the operating system is + allowed to do its best in buffering, sorting, and delaying + writes, so this can be a very big perfomance + increase. However, if the system crashes, parts of the data of + a transaction that has already been committed -- according to + the information on disk -- will still hang around in memory. + Inconsistent data (i.e., data corruption) is therefore likely + to occur. + + + + This option is the subject of an eternal debate in the + Postgres user and developer communities. Some + always leave it off, some turn it off only for bulk loads, + where there is a clear restart point if something goes wrong, + some leave it on just to be on the safe side. Because it is + the safe side, on is also the default. If you trust your + operating system, your utility company, and your hardware, you + might want to disable it. -- 2.40.0