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
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 |