rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add new Non-Durable Settings documentation section. 

Document that synchronous_commit can lose transactions in a db crash,
not just a OS crash.
This commit is contained in:
Bruce Momjian 2010-06-28 21:57:17 +00:00
parent 400916b6d7
commit c65f299894
2 changed files with 66 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/src/sgml/config.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.283 2010/06/25 13:11:25 sriggs Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.284 2010/06/28 21:57:17 momjian Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -1463,7 +1463,8 @@ SET ENABLE_SEQSCAN TO OFF;
really guaranteed to be safe against a server crash. (The maximum
delay is three times <xref linkend="guc-wal-writer-delay">.) Unlike
<xref linkend="guc-fsync">, setting this parameter to <literal>off</>
does not create any risk of database inconsistency: a crash might
does not create any risk of database inconsistency: an operating
system or database crash crash might
result in some recent allegedly-committed transactions being lost, but
the database state will be just the same as if those transactions had
been aborted cleanly. So, turning <varname>synchronous_commit</> off

64
doc/src/sgml/perform.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.80 2010/05/29 21:08:04 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.81 2010/06/28 21:57:17 momjian Exp $ -->
<chapter id="performance-tips">
<title>Performance Tips</title>
@ -1104,4 +1104,66 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
</sect2>
</sect1>
<sect1 id="non-durability">
<title>Non-Durable Settings</title>
<indexterm zone="non-durability">
<primary>non-durable</primary>
</indexterm>
<para>
Durability is a database feature that guarantees the recording of
committed transactions even if if the server crashes or loses
power. However, durability adds significant database overhead,
so if your site does not require such a guarantee,
<productname>PostgreSQL</productname> can be configured to run
much faster. The following are configuration changes you can make
to improve performance in such cases; they do not invalidate
commit guarantees related to database crashes, only abrupt operating
system stoppage, except as mentioned below:
<itemizedlist>
<listitem>
<para>
Place the database cluster's data directory in a memory-backed
file system (i.e. <acronym>RAM</> disk). This eliminates all
database disk I/O, but limits data storage to the amount of
available memory (and perhaps swap).
</para>
</listitem>
<listitem>
<para>
Turn off <xref linkend="guc-fsync">; there is no need to flush
data to disk.
</para>
</listitem>
<listitem>
<para>
Turn off <xref linkend="guc-full-page-writes">; there is no need
to guard against partial page writes.
</para>
</listitem>
<listitem>
<para>
Increase <xref linkend="guc-checkpoint-segments"> and <xref
linkend="guc-checkpoint-timeout"> ; this reduces the frequency
of checkpoints, but increases the storage requirements of
<filename>/pg_xlog</>.
</para>
</listitem>
<listitem>
<para>
Turn off <xref linkend="guc-synchronous-commit">; there might be no
need to write the <acronym>WAL</acronym> to disk on every
commit. This does affect database crash transaction durability.
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
</chapter>