The problem is that the information in the dictionary
element TD[] that is used to store information is
probably shared by all invocations of the function
within the transaction.
It is similar to the problem where all invokations
share a common SD[] for a particular function
in the scope of a connection.
That this is a bug or a feature is debateable.
Handling the memory scope is very tricky.
This is an educated guess. I have not looked at
the plpython code itself, altough I can vouch
for the behaviour.
elein
On Wednesday 14 May 2003 19:39, Tom Lane wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>
--
=============================================================
elein@varlena.com Database Consulting www.varlena.com
PostgreSQL General Bits http:/www.varlena.com/GeneralBits/
"Free your mind the rest will follow" -- en vogue