> > 3) Bug in ExecMergeJoin ??
> > This is something that has *NOTHING* to do with the Having logic!
> > Proof: Try the following query (without having my patch applied):
> >
> > select s.sid, s.sname, s.city
> > from supplier s
> > where s.sid+10 in (select se1.pid
> > from supplier s1, sells se1, part p1
> > where s1.sid=se1.sid and
> > s1.sname=s.sname and
> > se1.pid=p1.pid);
> >
> > (The file 'queries/create_insert.sql' included in the patch contains the
> > data for this, the query is included in 'queries/having.sql' !)
> >
> > As you can see, there is neither a having qual nor an aggregate
> > function used in the above query an you will see, it will fail!
> >
> > I found out that the reason for this is in the function
> > 'ExecMergeJoin()' in
> > switch (mergestate->mj_JoinState)
> > {
> > ....
> > case EXEC_MJ_NEXTOUTER:
> > ....
> > CleanUpSort(node->join.lefttree->lefttree);
> > CleanUpSort(node->join.righttree->lefttree);
> > ....
> > }
> >
> > In 'CleanUpSort()' the function 'psort_end()' gets called and
> > closes down the sort, which is correct as long as no subselects
> > are in use!
> >
> > I found out, that the bug does not appear when I comment the call
> > to 'psort_end()' out in 'CleanUpSort()'.
> >
> > I heavily tested the system after that and things worked well but
> > maybe this is just a lucky chance.
> >
> > So please, if anybody who has good knowledge of that part of the
> > code could have a look at that it would be great!
> >
> > I am sure the sort has to be ended at some time calling 'psort_end()'
> > but I did not have enough time to look for the right place. I was
> > just happy about the fact it produced some correct results and
> > stopped working on that.
I have looked into this, and it appears you are correct. The
psort_end() gets called with the T_Sort node is closed. Why they are
trying to close it in the Merge makes no sense to me. The psort calling
code in the executor was cleaned up around 6.2 because there were some
strange blocks of code in this section. Perhaps this is another area
where the code was called when it should not have been.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)