On 2021-Aug-13, David Christensen wrote:
> Both bugs #16676[1] and #17141[2] illustrate that the combination of
> SKIP LOCKED and FETCH FIRST WITH TIES break expectations when it comes
> to rows returned to other sessions accessing the same row. Since this
> situation is detectable from the syntax and hard to fix otherwise,
> forbid for now, with the potential to fix in the future.
I think we should do this, given that it has show potential to bite
people. We should also add a small mentioned to this in the docs, as in
the attached.
What do others think?
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Escucha y olvidarás; ve y recordarás; haz y entenderás" (Confucio)
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index fa676b1698..16bbab52c3 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1515,7 +1515,8 @@ FETCH { FIRST | NEXT } [ <replaceable class="parameter">count</replaceable> ] {
The <literal>WITH TIES</literal> option is used to return any additional
rows that tie for the last place in the result set according to
the <literal>ORDER BY</literal> clause; <literal>ORDER BY</literal>
- is mandatory in this case.
+ is mandatory in this case, and <literal>SKIP LOCKED</literal> is
+ not allowed.
<literal>ROW</literal> and <literal>ROWS</literal> as well as
<literal>FIRST</literal> and <literal>NEXT</literal> are noise
words that don't influence the effects of these clauses.
