Re: server process segfaulting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: James Gregory <james(at)anchor(dot)net(dot)au>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: server process segfaulting
Date: 2003-05-15 02:39:07
Message-ID: 4994.1052966347@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

James Gregory <james(at)anchor(dot)net(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martin Foster 2003-05-15 05:22:44 PostgreSQL Performance on OpenBSD
Previous Message James Gregory 2003-05-15 02:18:54 Re: server process segfaulting