Re: cache lookup failed for collation 0

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: cache lookup failed for collation 0
Дата
Msg-id 13113.1554997037@sss.pgh.pa.us
обсуждение исходный текст
Ответ на cache lookup failed for collation 0  (Jeevan Chalke <jeevan.chalke@enterprisedb.com>)
Ответы Re: cache lookup failed for collation 0  (Jeevan Chalke <jeevan.chalke@enterprisedb.com>)
Список pgsql-hackers
Jeevan Chalke <jeevan.chalke@enterprisedb.com> writes:
> Following test-sequence causing an error "cache lookup failed for collation 0";
> postgres:5432 [42106]=# create table foobar(a bytea primary key, b int);
> CREATE TABLE
> postgres:5432 [42106]=# insert into foobar
> values('\x4c835521685c46ee827ab83d376cf028', 1);
> INSERT 0 1
> postgres:5432 [42106]=# select * from foobar where a like '%1%';
> ERROR:  cache lookup failed for collation 0

Good catch!

> The error is coming from get_collation_isdeterministic() when colloid
> passed is 0. I think like we do in get_collation_name(), we should return
> false here when such collation oid does not exist.

Considering that e.g. lc_ctype_is_c() doesn't fail for InvalidOid, I agree
that it's probably a bad idea for get_collation_isdeterministic to fail.
There's a lot of code that thinks it can check for InvalidOid only in slow
paths.  However, I'd kind of expect the default result to be "true" not
"false".  Doing what you suggest would make match_pattern_prefix fail
entirely, unless we also put a special case there.

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_dump is broken for partition tablespaces
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Cleanup/remove/update references to OID column