Add note that LIMIT without ORDER BY can produce outright nondeterministic

results.  Necessary due to introduction of syncscan patch.

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index cfd32e80caef2be3df7f876c7a7fdfdcaaf6e489..b30d70b1067a6ada667480ac3964fa0cab27b083 100644 (file)
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -810,6 +810,14 @@ OFFSET <replaceable class="parameter">start</replaceable>
     to deliver the results of a query in any particular order unless
     <literal>ORDER BY</> is used to constrain the order.
    </para>
+
+   <para>
+    It is even possible for repeated executions of the same <literal>LIMIT</>
+    query to return different subsets of the rows of a table, if there
+    is not an <literal>ORDER BY</> to enforce selection of a deterministic
+    subset.  Again, this is not a bug; determinism of the results is
+    simply not guaranteed in such a case.
+   </para>
   </refsect2>
 
   <refsect2 id="SQL-FOR-UPDATE-SHARE">