As Aidan recently pointed out on performance-list
(http://archives.postgresql.org/pgsql-performance/2007-03/msg00110.php),
our documentation doesn't mention that CLUSTER isn't MVCC-safe.
The right way to fix it is to fix CLUSTER, of course, but we should
still document the current behavior in older branches.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/ref/cluster.sgml
===================================================================
RCS file: /home/hlinnaka/pgcvsrepository/pgsql/doc/src/sgml/ref/cluster.sgml,v
retrieving revision 1.40
diff -c -r1.40 cluster.sgml
*** doc/src/sgml/ref/cluster.sgml 1 Feb 2007 00:28:18 -0000 1.40
--- doc/src/sgml/ref/cluster.sgml 9 Mar 2007 11:52:27 -0000
***************
*** 100,105 ****
--- 100,116 ----
<title>Notes</title>
<para>
+ <command>CLUSTER</command> loses all visibility information of tuples,
+ which makes the table look empty to any snapshot that was taken
+ before the <command>CLUSTER</command> command finished. That makes
+ <command>CLUSTER</command> unsuitable for applications where
+ transactions that access the table being clustered are run concurrently
+ with <command>CLUSTER</command>. This is most visible with serializable
+ transactions, because they take only one snapshot at the beginning of the
+ transaction, but read-committed transactions are also affected.
+ </para>
+
+ <para>
In cases where you are accessing single rows randomly
within a table, the actual order of the data in the
table is unimportant. However, if you tend to access some
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
