From c65f29989493fccd7e0a08ead2435d57c5751dfe Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Mon, 28 Jun 2010 21:57:17 +0000
Subject: [PATCH] Add new Non-Durable Settings documentation section.
Document that synchronous_commit can lose transactions in a db crash,
not just a OS crash.
---
doc/src/sgml/config.sgml | 5 +--
doc/src/sgml/perform.sgml | 64 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 66 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 174f9814002..f218e698b24 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -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
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 4b6768bb694..10e38f2eb3d 100644
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -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>
--
GitLab