Re: server process segfaulting

We had this problem in spades when implementing the
C interface for informix. The problem is in allocation,
but it is a design problem, not a bug. The problem
is local to plpython and not plpgsql because only
plpython creates storage that can be accessed between
function calls. Special care must be taken to
ensure NEW and OLD are local to the instance and
not the statement. And so must some of the context storage.

There are several possible scopes for memory:
session, connection, transaction, statement*, one call
The semantics for statement are very hairy because
of the theoretical infinite nesting of subselects
and function calls.

The place to attack the problem starts with the
C interfaces. When allocating memory and attaching
it to the function call info, how long does it last?
Is the function writer expected to clean up?
Allocated data's scope should be well defined to be the single
instance of the function. Understanding these
things and then examining the semantics of python
dictionaries should lead to an understanding of sorts.

I take advantage of the plpython SD storage as
it stands and work around its limitations. This
will be fodder for my talk at oscon on running
aggregates.

If anyone really wants to tackle this, be prepared.
The memory scope issues are not simple, but they
should be easier in postgresql than in informix
because of the fe-be model.

D'Arcy should be involved and I'd really like to
go over scoping issues in more detail and perhaps
help avoid some of the worst pitfalls since I've
already done them.

Hmmm. I think I could be clearer. If anyone is
interested I can write something up.

elein

>From tgl(at)sss(dot)pgh(dot)pa(dot)us Tue Jun 3 19:48:28 2003
>X-UIDL: >Yc"!&F+!!6nR!!p2F!!
>To: James Gregory <james(at)anchor(dot)net(dot)au>
>cc: elein(at)varlena(dot)com, pgsql-general(at)postgresql(dot)org
>Subject: Re: [GENERAL] server process segfaulting
>In-reply-to: <1054690041(dot)3891(dot)56(dot)camel(at)pirate(dot)bridge(dot)anchor(dot)net(dot)au>
>References: <1052902703(dot)6429(dot)50(dot)camel(at)pirate(dot)bridge(dot)anchor(dot)net(dot)au> <1052965133(dot)6435(dot)57(dot)camel(at)pirate(dot)bridge(dot)anchor(dot)net(dot)au> <4994(dot)1052966347(at)sss(dot)pgh(dot)pa(dot)us> <200306011555(dot)19760(dot)elein(at)varlena(dot)com> <1054690041(dot)3891(dot)56(dot)camel(at)pirate(dot)bridge(dot)anchor(dot)net(dot)au>
>Comments: In-reply-to James Gregory <james(at)anchor(dot)net(dot)au>
> message dated "04 Jun 2003 11:27:22 +1000"
>Date: Tue, 03 Jun 2003 22:47:59 -0400
>From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>Content-Length: 897
>Lines: 20
>
>James Gregory <james(at)anchor(dot)net(dot)au> writes:
>> Is it worth tracing that through or is this not the problem?
>
>I believe the problem has been diagnosed as follows: the plpython stuff
>is assuming that any one trigger function will be used with only one
>tuple descriptor. Apply the same trigger function to two relations with
>different rowtypes, and you get a crash, because the initially-cached
>tuple descriptor is wrong for the second relation. It has nothing to do
>with storage allocation.
>
>I'm not sure whether the problem occurs with any PL languages besides
>plpython --- it seems like it could be a generic issue. I don't believe
>that plpgsql suffers from it, because it's too widely used: we'd have
>heard reports if it had the problem. But pltcl etc could have the same
>problem for all I know.
>
>You can check the archives once Marc gets the pieces put back
>together...
>
> regards, tom lane
>