Re: EvalPlanQual seems a tad broken

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