Lists: | pgsql-hackers |
---|
From: | Rémi Zara <remi_zara(at)mac(dot)com> |
---|---|
To: | peter_e(at)gmx(dot)net |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pika failing since the per-column collation patch |
Date: | 2011-02-12 12:34:42 |
Message-ID: | 234EC59E-DF5C-4D16-9CFD-B3319D8CD4C3@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hi,
Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started failing consistently with this diff:
*** /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/expected/polymorphism.out Sat Feb 12 02:16:07 2011
--- /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/results/polymorphism.out Sat Feb 12 09:10:21 2011
***************
*** 624,630 ****
-- 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
-- test variadic polymorphic functions
create function myleast(variadic anyarray) returns anyelement as $$
select min($1[i]) from generate_subscripts($1,1) g(i)
--- 624,630 ----
-- such functions must protect themselves if varying element type isn't OK
select max(histogram_bounds) from pg_stats;
! ERROR: locale operation to be invoked, but no collation was derived
-- test variadic polymorphic functions
create function myleast(variadic anyarray) returns anyelement as $$
select min($1[i]) from generate_subscripts($1,1) g(i)
Is there something I can do to help investigate this ?
Regards,
Rémi Zara
From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Rémi Zara <remi_zara(at)mac(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pika failing since the per-column collation patch |
Date: | 2011-02-12 17:51:16 |
Message-ID: | 1297533076.6286.3.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On lör, 2011-02-12 at 13:34 +0100, Rémi Zara wrote:
> Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started failing consistently with this diff:
>
> *** /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/expected/polymorphism.out Sat Feb 12 02:16:07 2011
> --- /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/results/polymorphism.out Sat Feb 12 09:10:21 2011
> ***************
> *** 624,630 ****
>
> -- 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
> -- test variadic polymorphic functions
> create function myleast(variadic anyarray) returns anyelement as $$
> select min($1[i]) from generate_subscripts($1,1) g(i)
> --- 624,630 ----
>
> -- such functions must protect themselves if varying element type isn't OK
> select max(histogram_bounds) from pg_stats;
> ! ERROR: locale operation to be invoked, but no collation was derived
> -- test variadic polymorphic functions
> create function myleast(variadic anyarray) returns anyelement as $$
> select min($1[i]) from generate_subscripts($1,1) g(i)
>
> Is there something I can do to help investigate this ?
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.
From: | Rémi Zara <remi_zara(at)mac(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pika failing since the per-column collation patch |
Date: | 2011-02-14 18:27:51 |
Message-ID: | 669E50C5-3EF6-48BF-B39A-614EBB206B46@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit :
> On lör, 2011-02-12 at 13:34 +0100, Rémi Zara wrote:
>> Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started failing consistently with this diff:
>>
>> *** /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/expected/polymorphism.out Sat Feb 12 02:16:07 2011
>> --- /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/results/polymorphism.out Sat Feb 12 09:10:21 2011
>> ***************
>> *** 624,630 ****
>>
>> -- 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
>> -- test variadic polymorphic functions
>> create function myleast(variadic anyarray) returns anyelement as $$
>> select min($1[i]) from generate_subscripts($1,1) g(i)
>> --- 624,630 ----
>>
>> -- such functions must protect themselves if varying element type isn't OK
>> select max(histogram_bounds) from pg_stats;
>> ! ERROR: locale operation to be invoked, but no collation was derived
>> -- test variadic polymorphic functions
>> create function myleast(variadic anyarray) returns anyelement as $$
>> select min($1[i]) from generate_subscripts($1,1) g(i)
>>
>> Is there something I can do to help investigate this ?
>
> 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).
Regards,
Rémi Zara
From: | Rémi Zara <remi(dot)zara(at)free(dot)fr> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pika failing since the per-column collation patch |
Date: | 2011-02-16 22:06:23 |
Message-ID: | 052C4354-0A18-45D5-AAAC-2EF27A63ACF8@free.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit :
>
> 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).
>
Hi,
Without me changing anything (still at -O0), the same error occurred but at the installCheck step, rather than the check step (which passed)
Anything else to try ?
Regards,
Rémi Zara
From: | Rémi Zara <remi_zara(at)mac(dot)com> |
---|---|
To: | Rémi Zara <remi_zara(at)mac(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pika failing since the per-column collation patch |
Date: | 2011-02-16 22:13:25 |
Message-ID: | 38AEC939-C56D-436C-982A-B011CD6DE54B@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit :
>
> 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).
>
Hi,
Without me changing anything (still at -O0), the same error occurred but at the installCheck step, rather than the check step (which passed)
Anything else to try ?
Regards,
Rémi Zara
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rémi Zara <remi_zara(at)mac(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pika failing since the per-column collation patch |
Date: | 2011-02-18 07:26:25 |
Message-ID: | 12004.1298013985@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
=?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
From: | Rémi Zara <remi_zara(at)mac(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pika failing since the per-column collation patch |
Date: | 2011-02-27 21:56:28 |
Message-ID: | 04B7B49C-788F-455E-8C22-B592F3E4A67C@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Le 18 févr. 2011 à 08:26, Tom Lane a écrit :
> =?iso-8859-1?Q?R=E9mi_Zara?= <remi_zara(at)mac(dot)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