Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Дата
Msg-id 201103051837.31170.andres@anarazel.de
обсуждение исходный текст
Ответ на Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)  (Andres Freund <andres@anarazel.de>)
Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)  (Andres Freund <andres@anarazel.de>)
Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Saturday 05 March 2011 17:46:13 Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On Saturday 05 March 2011 04:44:20 Robert Haas wrote:
> >>> * Collation-related regression failure on buildfarm member pika.  This
> >>> is clearly a bug we need to identify, but maybe we can ship the alpha
> >>> without a fix --- for one thing, getting more than one report of the
> >>> problem would be helpful.
> > 
> > I have just yesterday hit the same bug while testing some application on
> > then HEAD, so its not just PIKA.
> 
> What platform, and what locale/encoding environment?
One debian and one ubuntu x64 box.

I have a WIP patch fixing one of the two issues.

Several places in selfuncs.c didn't setup collations. That lead for example to 
errors during patternsel.

The eqproc don't actually currently need the collation information, but I 
think it is more consistent.

(attached)

I am currently looking at the other one. Its quite strange:

I can trigger it reliably on my machines.
with gdb attached:

b indexam.c:875 (thats index_getprocinfo)
...

test=# CREATE TABLE foo(a int, b text, c int);
CREATE TABLE
Time: 65.535 ms

test=# INSERT INTO foo VALUES (1, '1', 2);
INSERT 0 1
Time: 66.777 ms

test=# INSERT INTO foo VALUES (1, '2', 2);
INSERT 0 1
Time: 40.687 ms

#play with gdb

test=# CREATE INDEX foo_abc ON foo (a, b,c);
ERROR:  locale operation to be invoked, but no collation was derived


...
(gdb) print irel->rd_indcollation[0]
$8 = 0
(gdb) print irel->rd_indcollation[1]
$9 = 100
(gdb) print irel->rd_indcollation[2]
$10 = 0
(gdb) 
$11 = 0
(gdb) print irel->rd_index->indcollation.values[0]
$12 = 0
(gdb) print irel->rd_index->indcollation.values[1]
$13 = 0
(gdb) print irel->rd_index->indcollation.values[2]
$14 = 100
(gdb) print irel->rd_index->indcollation.values[3]
$15 = 0
(gdb) print irel->rd_index->indcollation
$16 = {vl_len_ = 8, ndim = 144, dataoffset = 1, elemtype = 0, dim1 = 26, 
lbound1 = 3, values = {0}}


The piece of code using indcollation assumes that dataoffset = 0 which seems to 
be an valid assumption...
...    fmgr_info_collation(irel->rd_index->indcollation.values[attnum-1],                        locinfo);
...

Thus no valid collation is attached for the text column but a useless one for 
the last int column.

Andres




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Extensions vs. shared procedural language handler functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extensions vs. shared procedural language handler functions