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

-<!-- $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

doc/src/sgml/perform.sgml

-<!-- $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>