Re: server process segfaulting - Mailing list pgsql-general

From Tom Lane
Subject Re: server process segfaulting
Date
Msg-id 4994.1052966347@sss.pgh.pa.us
Whole thread Raw
In response to Re: server process segfaulting  (James Gregory <james@anchor.net.au>)
Responses Re: server process segfaulting  (elein <elein@varlena.com>)
List pgsql-general
James Gregory <james@anchor.net.au> writes:
> On Thu, 2003-05-15 at 01:53, Tom Lane wrote:
>> Um.  There was a report that plpython triggers get confused if you try
>> to apply the same trigger procedure to multiple tables (it tries to use
>> the first table's row descriptor with all the other tables, and yes that
>> can lead to a segfault).

> Is it only plpython that has the problem?

I'm not sure.  It's only been reported against plpython, but it seems
possible that our other PLs might have the same bug.  I'd only be
willing to bet that plpgsql doesn't have it, because that's the most
heavily used PL and someone woulda noticed by now...

> If I wanted to fix this where
> would I start looking? presumably pgsql/src/plpython/plpython.c. Do you
> have a link with more info about the bug by any chance?

Not offhand, but if you search the PG list archives you will find the bug
report.  I think it was back around the beginning of this year.

If fading memory serves, I suggested a quick-hack solution of including
the target table's OID into the Python name of the function (so that
triggers on different tables are automatically different Python objects)
but whoever it was that was promising to do the legwork wanted to look
for a cleaner approach.

At this point I've lost faith in whoever-it-was, and would gladly accept
a patch based on the quick-hack approach.

            regards, tom lane

pgsql-general by date:

Previous
From: James Gregory
Date:
Subject: Re: server process segfaulting
Next
From: Himmet Karaman
Date:
Subject: TESTING the DATABASE