<p dir="ltr">On 14/02/2016 5:11 pm, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>
wrote:<br/> ><br /> > David Rowley <<a
href="mailto:david.rowley@2ndquadrant.com">david.rowley@2ndquadrant.com</a>>writes:<br /> > > On 12/02/2016
12:01am, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /> > > I can't
quiteunderstand what you're seeing here.<br /> ><br /> > The second loop is iterating through the original GROUP
BYlist, so it<br /> > will see again any outer Vars that were excluded by the first loop.<br /> > It needs to
excludethem exactly the same, because they are outside<br /> > the scope of its data structures. Consider something
like(admittedly<br /> > pretty silly, but legal SQL)<br /> ><br /> > create table up (u1 int, u2 int, u3
int);<br/> > create table down (f1 int primary key, f2 int);<br /> ><br /> > select * from othertable, up<br
/>> where u1 in (select f2 from down group by f1, f2, up.u3);<br /> ><br /> > up.u3 would have varlevelsup =
1,varno = 2, varattno = 3.<br /> > If you don't skip it then the surplusvars[var->varno] access<br /> > will
betrying to fetch off the end of the surplusvars[] array,<br /> > because there is only one RTE in the subquery's
rangetable<br/> > though there are two in the outer query's rangetable.<p dir="ltr">Thanks for explaining this.
ClearlyI missed the case of the varno pointing off the end of the array. Thanks for noticing and fixing. <br />