Re: tsearch2 problem rank_cd() (possibly) crashing postgres - Mailing list pgsql-admin

From Tom Lane
Subject Re: tsearch2 problem rank_cd() (possibly) crashing postgres
Date
Msg-id 5964.1165594374@sss.pgh.pa.us
Whole thread Raw
In response to tsearch2 problem rank_cd() (possibly) crashing postgres  ("Rajesh Kumar Mallah" <mallah.rajesh@gmail.com>)
Responses Re: tsearch2 problem rank_cd() (possibly) crashing postgres
List 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 by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: tsearch2 problem rank_cd() (possibly) crashing postgres
Next
From: "Joshua D. Drake"
Date:
Subject: Re: tsearch2 problem rank_cd() (possibly) crashing postgres