database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-23 03:21:12 +03:00
Code Activity

Update description of fsync option for 7.1.

Browse Source
This commit is contained in:
Tom Lane
2001-02-18 05:30:12 +00:00
parent 57e0847180
commit c3151c29de
1 changed files with 20 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
doc/src/sgml/runtime.sgml
View File

@ -1,5 +1,5 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.54 2001/02/16 19:43:52 momjian Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.55 2001/02/18 05:30:12 tgl Exp $
--> -->
<Chapter Id="runtime"> <Chapter Id="runtime">
@ -936,28 +936,26 @@ env PGOPTIONS='-c geqo=off' psql
<term>FSYNC (<type>boolean</type>)</term> <term>FSYNC (<type>boolean</type>)</term>
<listitem> <listitem>
<para> <para>
If this is option is on, the <productname>Postgres</> backend If this option is on, the <productname>Postgres</> backend
will use the <function>fsync()</> system call in several will use the <function>fsync()</> system call in several
places to make sure that updates are physically written to places to make sure that updates are physically written to
disk and will not hang around in the write caches. This disk and do not hang around in the kernel buffer cache. This
increases the chance that a database installation will still increases the chance that a database installation will still
be usable after a operating system or hardware crashes by a be usable after an operating system or hardware crash by a
large amount. (Crashes of the database server itself do large amount. (Crashes of the database server itself do
<emphasis>not</> affect this consideration.) <emphasis>not</> affect this consideration.)
</para> </para>
<para> <para>
However, this operation severely slows down However, this operation slows down <productname>Postgres</>,
<productname>Postgres</>, because at all those points it has because at all those points it has
to block and wait for the operating system to flush the to block and wait for the operating system to flush the
buffers. Without <function>fsync</>, the operating system is buffers. Without <function>fsync</>, the operating system is
allowed to do its best in buffering, sorting, and delaying allowed to do its best in buffering, sorting, and delaying
writes, so this can be a <emphasis>very</> big perfomance writes, which can make for a considerable perfomance
increase. However, if the system crashes, parts of the data of increase. However, if the system crashes, the results of the
a transaction that has already been committed -- according to last few committed transactions may be lost in part or whole;
the information on disk -- will still hang around in memory. in the worst case, unrecoverable data corruption may occur.
Inconsistent data (i.e., data corruption) is therefore likely
to occur.
</para> </para>
<para> <para>
@ -967,8 +965,16 @@ env PGOPTIONS='-c geqo=off' psql
where there is a clear restart point if something goes wrong, 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 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 the safe side, on is also the default. If you trust your
operating system, your utility company, and your hardware, you operating system, your hardware, and your utility company (or
might want to disable it. better your UPS), you might want to disable fsync.
</para>
<para>
It should be noted that the performance penalty from doing
fsyncs is considerably less in <productname>Postgres</> version
7.1 than it was in prior releases. If you previously suppressed
fsyncs because of performance problems, you may wish to reconsider
your choice.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>