Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 5. Now commit in the second session. First session resumes and
> prints
>
> f1 | f2 | f3 | f4
> ----+----+----+-----
> 1 | 1 | 1 | 111
> 1 | 1 | 1 | 112
> 2 | 42 | 2 | 113
> 2 | 42 | 2 | 114
> 2 | 42 | 2 | 113
> 2 | 42 | 2 | 114
> (6 rows)
>
> Of course the expected answer is
>
> f1 | f2 | f3 | f4
> ----+----+----+-----
> 1 | 1 | 1 | 111
> 1 | 1 | 1 | 112
> 2 | 42 | 2 | 113
> 2 | 42 | 2 | 114
> (4 rows)
>
> which is what you'll get if you simply repeat the test query.
Is this related to issue 4593? (SELECT FOR UPDATE can return results
in a sequence inconsistent with actual result rows and the ORDER BY
clause -- rows are ordered by the pre-UPDATE values, while the results
show the post-UPDATE values.)
http://archives.postgresql.org/pgsql-bugs/2009-01/msg00017.php
On the face of it, it seems very similar. Will the patch address this
anomaly of SELECT FOR UPDATE, too?
-Kevin
