Re: server process segfaulting
От | Tom Lane |
---|---|
Тема | Re: server process segfaulting |
Дата | |
Msg-id | 24628.1052927627@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | server process segfaulting (James Gregory <james@anchor.net.au>) |
Ответы |
Re: server process segfaulting
|
Список | pgsql-general |
James Gregory <james@anchor.net.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
В списке pgsql-general по дате отправления: