Horton

Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pgsql-bugs@lists.postgresql.org, v.g.baranoff@gmail.com
Date: 2018-08-17T13:59:16Z
Lists: pgsql-bugs 
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>  Andrew> I'm guessing that locally saving/restoring the scan direction
>  Andrew> in ExecSubPlan is going to be the best option; it seems to fix
>  Andrew> the problem, I'll post a patch in a bit.

> It turns out to be also necessary to do this in ExecSetParamPlan, though
> I couldn't find a way to make a stable regression test for that - my
> manual tests were based on putting a subselect inside a volatile
> construct like CASE WHEN random() < x THEN.

Looks sane to me ... and a bit astonishing that we didn't run into
this a decade or two back.

			regards, tom lane

Commits

  1. Set scan direction appropriately for SubPlans (bug #15336)

  2. Get rid of the separate EState for subplans, and just let them share the