|
1 | 1 | <!-- |
2 | | -$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.14 2000/07/15 21:35:47 petere Exp $ |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.15 2000/07/16 14:47:57 petere Exp $ |
3 | 3 | --> |
4 | 4 |
|
5 | 5 | <Chapter Id="runtime"> |
@@ -846,11 +846,39 @@ env PGOPTIONS='--geqo=off' psql |
846 | 846 | <term>FSYNC (<type>boolean</type>)</term> |
847 | 847 | <listitem> |
848 | 848 | <para> |
849 | | - When this is on (default), an <function>fsync()</function> |
850 | | - call is done after each transaction. Turning this off |
851 | | - increases performance but an operating system crash or power |
852 | | - outage might cause data corruption. (Note that a crash of |
853 | | - <productname>Postgres</productname> itself is not affected.) |
| 849 | + If this is option is on, the <productname>Postgres</> backend |
| 850 | + will use the <function>fsync()</> system call in several |
| 851 | + places to make sure that updates are physically written to |
| 852 | + disk and will not hang around in the write caches. This |
| 853 | + increases the chance that a database installation will still |
| 854 | + be usable after a operating system or hardware crashes by a |
| 855 | + large amount. (Crashes of the database server itself do |
| 856 | + <emphasis>not</> affect this consideration.) |
| 857 | + </para> |
| 858 | + |
| 859 | + <para> |
| 860 | + However, this operation severely slows down |
| 861 | + <productname>Postgres</>, because at all those points it has |
| 862 | + to block and wait for the operating system to flush the |
| 863 | + buffers. Without <function>fsync</>, the operating system is |
| 864 | + allowed to do its best in buffering, sorting, and delaying |
| 865 | + writes, so this can be a <emphasis>very</> big perfomance |
| 866 | + increase. However, if the system crashes, parts of the data of |
| 867 | + a transaction that has already been committed -- according to |
| 868 | + the information on disk -- will still hang around in memory. |
| 869 | + Inconsistent data (i.e., data corruption) is therefore likely |
| 870 | + to occur. |
| 871 | + </para> |
| 872 | + |
| 873 | + <para> |
| 874 | + This option is the subject of an eternal debate in the |
| 875 | + <productname>Postgres</> user and developer communities. Some |
| 876 | + always leave it off, some turn it off only for bulk loads, |
| 877 | + where there is a clear restart point if something goes wrong, |
| 878 | + some leave it on just to be on the safe side. Because it is |
| 879 | + the safe side, on is also the default. If you trust your |
| 880 | + operating system, your utility company, and your hardware, you |
| 881 | + might want to disable it. |
854 | 882 | </para> |
855 | 883 | </listitem> |
856 | 884 | </varlistentry> |
|