Le 18 févr. 2011 à 08:26, Tom Lane a écrit : > =?iso-8859-1?Q?R=E9mi_Zara?= <remi_z...@mac.com> writes: >> Le 12 févr. 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. >
Hi, Here is what I get after adding an elog in varstr_cmp: WARNING: Comparing "B011 " and "<fetch first clause> in subqueries^?^?\xa0" ERROR: locale operation to be invoked, but no collation was derived STATEMENT: select max(histogram_bounds) from pg_stats; Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
