Re: [HACKERS] pika failing since the per-column collation patch

2011-02-27 Thread Rémi Zara

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


Re: [HACKERS] pika failing since the per-column collation patch

2011-02-17 Thread Rémi Zara

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
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pika failing since the per-column collation patch

2011-02-17 Thread Tom Lane
=?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.

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


Re: [HACKERS] pika failing since the per-column collation patch

2011-02-16 Thread Rémi Zara

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pika failing since the per-column collation patch

2011-02-14 Thread Rémi Zara

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
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pika failing since the per-column collation patch

2011-02-12 Thread Peter Eisentraut
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.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers