Re: pika failing since the per-column collation patch
От | Tom Lane |
---|---|
Тема | Re: pika failing since the per-column collation patch |
Дата | |
Msg-id | 12004.1298013985@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pika failing since the per-column collation patch (Rémi Zara <remi_zara@mac.com>) |
Ответы |
Re: pika failing since the per-column collation patch
|
Список | pgsql-hackers |
Rémi Zara <remi_zara@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. regards, tom lane
В списке pgsql-hackers по дате отправления: