Thread: cash_out bug

Hello:

I was investigating the bug about "select cash_out(2)" crashing the
backend.  I thought fixing was a simple matter of checking whether some
argument to the function was NULL or not.

I added a NULL checking, but it obviously is not triggered, because the
data received is not NULL, but a non-pointer integer that cannot be
dereferenced (doing so cause a segmentation fault).

It turns out to be a far more serious bug than that, and is not limited
to cash_out.  All these functions have the same problem:

select proname from pg_proc where proargtypes=(select proargtypes from
pg_proc where proname='cash_in') and pronargs=1 and proisstrict='t'
order by proname;

With a few exceptions (the test(*) is long, as it requires one to wait for
the database to start after testing each function, but there are 16 out
of 107 functions(**) that cause backend crash).

The problem is related to PG_GETARG_POINTER in some way or another; the
dereferencing of a non-pointer integer makes the backend crash.

I, however, do not know how to fix this.  I'm just pointing out this
problem so someone more knowledgeable than me with this pointer mess can
figure a way out.

(*) The test is
SELECT="select proname from pg_proc where proargtypes=''
and pronargs=1 and proisstrict='t' order by proname;"

for i in `psql regression -c "$SELECT"`; doecho $i >> func_testpsql regression -c "select $i(1);" >> func_test
2>&1sleep9
 
done

(**) Those are:
boolout
charout
cidout
date_out
int2out
int4out
nabstimeout
oidout
regclassout
regoperatorout
regoperout
regprocedureout
regprocout
regtypeout
reltimeout
smgrout
xidout

-- 
Alvaro Herrera (<alvherre[a]atentus.com>)
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)

I said:

> It turns out to be a far more serious bug than that, and is not limited
> to cash_out.  All these functions have the same problem:
> 
> With a few exceptions (the test(*) is long, as it requires one to wait for
> the database to start after testing each function, but there are 16 out
> of 107 functions(**) that cause backend crash).

This should read "16 out of 107 that do _not_ cause backend crash".

-- 
Alvaro Herrera (<alvherre[a]atentus.com>)
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)

> It turns out to be a far more serious bug than that, and is not limited
> to cash_out.  All these functions have the same problem:
>
> select proname from pg_proc where proargtypes=(select proargtypes from
> pg_proc where proname='cash_in') and pronargs=1 and proisstrict='t'
> order by proname;

Is this a problem in that the functions are definined to return opaque (eg.
PG_RETURN_VOID) but are then still usable in SELECT statements?

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Is this a problem in that the functions are definined to return opaque (eg.
> PG_RETURN_VOID) but are then still usable in SELECT statements?

The issue here is (once again) that we're overloading type oid 0
("opaque") to mean too many different, incompatible things.  I've
ranted about this before and will not repeat my previous remarks.
The bottom line is that we need to eliminate "opaque" in favor of
a set of pseudo-datatypes with different, crisply-defined semantics.
We've had some discussions about it but no complete proposal has been
made.  Since eliminating "opaque" is going to break just about every
extant user-defined datatype, I'm not in a hurry to do it until we
can get it right the first time...
        regards, tom lane

> The issue here is (once again) that we're overloading type oid 0
> ("opaque") to mean too many different, incompatible things.  I've
> ranted about this before and will not repeat my previous remarks.
> The bottom line is that we need to eliminate "opaque" in favor of
> a set of pseudo-datatypes with different, crisply-defined semantics.
> We've had some discussions about it but no complete proposal has been
> made.  Since eliminating "opaque" is going to break just about every
> extant user-defined datatype, I'm not in a hurry to do it until we
> can get it right the first time...

I guess if anyone were to make a complete proposal, it would have to be you
then methinks...  Is it worth starting a thread about it at this stage?  It
is a pretty serious problem.

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Is it worth starting a thread about it at this stage?  It
> is a pretty serious problem.

I agree, but given the lack of movement over the last couple years,
I'm not expecting a solution to suddenly emerge for 7.3 ...
        regards, tom lane