Ah. Finally after trying to stare down the code for some more time the issue
is pretty simple.
index_getprocinfo did this:
/* Initialize the lookup info if first time through */if (locinfo->fn_oid == InvalidOid){
... fmgr_info_cxt(procId, locinfo, irel->rd_indexcxt);
fmgr_info_collation(irel->rd_index->indcollation.values[attnum-1], locinfo);}
which is not a good idea because irel->rd_index->indcollation is field after
the variable lenght indkey field.
Indkey is of int2vector type which is important because it means that there is
enough space for a second key without making direct access to indcollation
wrong (which is 4byte alligned). That explains why the issue could only be
triggered by a composite index covering at least 3 columns...
RelationInitIndexAccessInfo already fills the more convenient
Relation.rd_indcollation which makes the fix trivial.
It was a good bug though, because now I understand the relcache to some degree
which I formerly definitely did not ;-)
On Saturday 05 March 2011 18:37:30 Andres Freund wrote:
> 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
> test=# CREATE INDEX foo_abc ON foo (a, b,c);
> ERROR: locale operation to be invoked, but no collation was derived
Fixed after applying the patch.
Andres
