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-14 15:53:47
Message-ID: 24628.1052927627@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:
> The logs from the point where it is dying are below. The last queries
> before the segfault are coming from a trigger I wrote in plpython to do
> referential integrity checking for inherited tables (I posted about it
> before writing said code).

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

AFAIR this is still unfixed in CVS tip --- someone had volunteered to
produce a fix, but it has not materialized yet. In the meantime, you
need to make a separate trigger function for each table :-(

> In point 3 it seems to suggest that if the schema of any of the tables
> change, then the plpython functions will need to be recreated.

I don't think you need to recreate them, just start a fresh session.
The cached row descriptors are only cached within a backend.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2003-05-14 15:55:13 Re: COPY versus INSERT
Previous Message Richard Huxton 2003-05-14 15:51:18 Re: - what protocol for an Internet postgres connection