Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.10.1/8.10.1) with ESMTP id e7MEWdT77608 for ; Tue, 22 Aug 2000 10:32:39 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA05779; Tue, 22 Aug 2000 10:32:29 -0400 (EDT) To: "Joonas Makkonen" cc: pgsql-interfaces@postgresql.org Subject: Re: SPI_connect problems In-reply-to: <024201c00c17$d5f66610$e62689c2@infosto.fi> References: <024201c00c17$d5f66610$e62689c2@infosto.fi> Comments: In-reply-to "Joonas Makkonen" message dated "Tue, 22 Aug 2000 12:03:24 +0300" Date: Tue, 22 Aug 2000 10:32:28 -0400 Message-ID: <5776.966954748@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200008/123 "Joonas Makkonen" writes: > I have a trigger function written in C that uses SPI to fetch certain data > from the db. The problem is that about 20% of the time SPI_connect() > returns: > NOTICE: SPI_connect() failed in RI_FKey_check() > Any ideas what might be causing this? It looks like you have some referential integrity triggers in your database that are getting fired during the query you execute from your SPI call. The RI triggers also use SPI. Recursive entry to SPI is supposed to work, but evidently SPI_connect() isn't happy. After a quick look at the code (see src/backend/executor/spi.c) it seems the only way that could happen is if there's a mismatch of SPI_push and SPI_pop operations, leaving _SPI_curid pointing at the wrong stack level. This might be your error, or it might be a bug in the RI trigger code or in SPI itself. I'd suggest tracing through the SPI operations (use a debugger, or insert printf()s) until you understand what's happening. BTW, the RI code is in src/backend/utils/adt/ri_triggers.c regards, tom lane