Tom Lane <t...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
