Andres Freund <and...@anarazel.de> writes:
> On Saturday 05 March 2011 17:46:13 Tom Lane wrote:
>> Andres Freund <and...@anarazel.de> writes:
>>>> * Collation-related regression failure on buildfarm member pika. This
>>>> is clearly a bug we need to identify, but maybe we can ship the alpha
>>>> without a fix --- for one thing, getting more than one report of the
>>>> problem would be helpful.
>>> I have just yesterday hit the same bug while testing some application on
>>> then HEAD, so its not just PIKA.
>> What platform, and what locale/encoding environment?
> One debian and one ubuntu x64 box.
> I have a WIP patch fixing one of the two issues.
> Several places in selfuncs.c didn't setup collations. That lead for example
> to
> errors during patternsel.
I've applied these changes as part of my last commit. However, I now
believe that this has nothing to do with pika's problem and we're not
going to see it go green :-(
I'm pretty well convinced that what is happening on pika is that the
first two rows of histogram_bounds data processed by the max() aggregate
happen to be of collatable types, but since the aggregate is over
anyarray it has no collation to pass to the array_larger() function,
so it fails with that error instead of the expected one. I don't know
exactly why we see that fail consistently on that machine and not any
other buildfarm machines, but it doesn't matter --- the outcome is
clearly possible.
We could add a variant expected-output file for the polymorphism test,
but I don't really want to take on the added maintenance burden.
I think it'd be best to just add a WHERE clause to the failing query
that will restrict the set of rows considered so that they don't include
any columns of collatable types. If pika's next run doesn't show green
then I'll do that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
