Re: tsearch2 problem rank_cd() (possibly) crashing postgres

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: tsearch2 problem rank_cd() (possibly) crashing postgres
Дата
Msg-id 5964.1165594374@sss.pgh.pa.us
обсуждение исходный текст
Ответ на tsearch2 problem rank_cd() (possibly) crashing postgres  ("Rajesh Kumar Mallah" <mallah.rajesh@gmail.com>)
Ответы Re: tsearch2 problem rank_cd() (possibly) crashing postgres  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-admin
"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Fri, 2006-12-08 at 10:47 -0500, Tom Lane wrote:
>> Nonetheless, dumping core on bad input is not acceptable behavior ...

> Is it time to require test cases for contrib modules?

tsearch2 *has* a regression test.  ATM it sounds like the problem is
that the OP tried to use a new library with old pg_proc entries that
defined different parameter sets for the same-named C functions; a
situation that no regression test would have exercised anyway.

That change was probably unwise on Oleg and Teodor's part, but what's
done is done.  My point is that now that we know the failure mode, we
need to add some defenses.  The OP is certainly not the last DBA who
will make this mistake during 8.1->8.2 upgrade.

It looks to me like the problem is that with the old pg_proc entries,
an "int4" will get passed where the code is expecting "float4[]",
so it tries to dereference the int and crashes.  There doesn't seem
to be any real cheap defense --- we might have to add a
get_fn_expr_argtype() call into rank_cd, and anything else that's been
changed similarly.  But I don't think this is negotiable.  Backend
crashes are bad.

            regards, tom lane

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

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: tsearch2 problem rank_cd() (possibly) crashing postgres
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: tsearch2 problem rank_cd() (possibly) crashing postgres