Re: pika failing since the per-column collation patch

=?iso-8859-1?Q?R=E9mi_Zara?= <remi_zara(at)mac(dot)com> writes:
> Le 12 fvr. 2011 18:51, Peter Eisentraut a crit :
>> It's only failing on this one machine, but there isn't anything
>> platform-specific in this code, so I'd look for memory management faults
>> on the code or a compiler problem. Try with lower optimization for a
>> start.

> Same failure with -O0 (and more shared memory).

Note that the query that is failing is an intentional probe of
robustness:

-- check that we can apply functions taking ANYARRAY to pg_stats ...
-- such functions must protect themselves if varying element type isn't OK
select max(histogram_bounds) from pg_stats;
ERROR: cannot compare arrays of different element types

pika is instead showing

ERROR: locale operation to be invoked, but no collation was derived

which some trawling through the code says is coming from varstr_cmp
when fn_collation didn't get set on the call.

Hypothesis: the platform-dependency here is just one of row ordering,
to wit, on most platforms the scan of pg_statistic fails before it gets
to the case where the collation issue is triggered. I'm suspicious that
if two text arrays get compared via this code path, fn_collation fails
to get set, and it's not a platform-specific omission.

It'd be helpful if you could identify the specific values that are
getting compared at the moment of the failure.

regards, tom lane