2009/7/13 Tom Lane <tgl@sss.pgh.pa.us>:
> 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
