On Fri, Apr 3, 2015 at 5:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... btw, has anyone noticed that this patch broke hamerkop and
> bowerbird? Or at least, it's hard to see what other recent commit
> would explain the failures they're showing.
I noticed the failure on bowerbird today and I agree that looks an
awful lot like it might be this patch's fault. The failure on
hamerkop looks like the same issue. I'm a bit at a loss to explain
exactly what has gone wrong there. What those machines have in common
is that they are the only 64-bit Windows machines using the Microsoft
toolchain in the buildfarm, but I don't know why that should provoke a
failure. I seem to remember having some trouble previously with
Microsoft compilers being finickier than others about a shift with a
width greater than or equal to the bit-width of the value, but if
there is such a problem here, I can't spot it. Nor do I see a
compiler warning in numeric.c which might provide a clue.
For those following along at home, the failures are on these queries:
SELECT 1.1 AS two UNION SELECT 2.2;
SELECT 1.1 AS two UNION SELECT 2;
SELECT 1 AS two UNION SELECT 2.2;
SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELECT 2;
In each case, the expected result is with the values in ascending
numerical order. In each case, the 1 or 1.1 value which ought to
appear before 2 or 2.2 instead appears after it. Strictly speaking,
this is not the wrong answer to the query, and could be perhaps
explained by the planner choosing a hash aggregate rather than a sort
+ unique plan. But this patch doesn't change the planner at all, so
the plan should be the same as it has always been. And if it is
choosing to sort, then it's clearly doing it wrong, but there doesn't
seem to be anything platform-specific about this code, so I'm
mystified.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company