2009/7/13 Tom Lane <tgl@xxxxxxxxxxxxx>: > No, you're misinterpreting the message. What that code likely means > is that something is trying to use SPI and finding plpgsql already > connected. In other words, plpgsql forgets to do a SPI_push() before > calling something that might try to use SPI re-entrantly. It should be > perfectly deterministic and it definitely doesn't have anything to do > with the states of other sessions. But we're going to need a test > case to fix it. > Tom, I'm not able to prepare a test case - the error is thrown exactly in two queries, but those queries can be executed without that error - there is no rule, when it will be thrown. When the error was thrown both queries cannot be executed (in the same connection of course, but in other connections they can be executed without problem). Before the error is thrown both queries were executed successfully (I'm logging all "mod" queries), but at some moment (unknown for me) the error is thrown and as I wrote those queries cannot be executed in current connection anymore - what is really strange is the fact that other queries (both selects and updates) can be executed in that connection and there some of those queries fires plpgsql triggers which updates db data (so SPI is used??). What can I do ? I don't want to do the downgrade :-( How can I track the moment, when plpgsql forgets to do SPI_push() ? I'm really appreciated for your help. ML -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
