Hi,
> Hmph. So evidently the unexpected recursion into SPI is happening when
> a cached plan has to be recomputed. I suspected something of the sort,
> but now the question is why you didn't see the same problem in 8.3 ...
Just as an additional confirmation: nothing else but the db changed when we
migrated from 8.3.7 to 8.4.0 last weekend
Anything else I can do to assist?
FYI:
- the production site today ran into this problem just over a thousand times
resulting in the same number of rollbacks and reconnects (since that solves it
for a little while again), so needless to say there's some additional
motivation to help ;)
- with relation to recomputation of cached plans: our usage patterns basically
do not include DDL, with the exception of temp tables; the functions that bail
are all using a single table each, the records of which are not changing in
any way
- we use before/after and deferred triggers, all in sql or pgsql; we use a
single after-trigger written in C for keeping track of history, which does its
own SPI_connect/finish calls, but as stated earlier, all of this was in place
a long time when we were running 8.3.7, though obviously the C-trigger has
been recompiled
- the distribution over triggers / functions that run into this error seems
uneven, basically they all boil down to a couple of custom functions, the
specifics of which I described earlier (same structure, immutable, use
exception thus an extra begin/end block, etc), but since we have loads of
other simular functions that don't come up, it's hard to see what would be
special here
Depending on the other idea's you might have, we could fairly easily
temporarily redefine one or more of the pgsql functions that suffer from this
error as plain sql functions, just to see what would happen.......?
(I'm reaching, I know ;) )
--
Best,
Frank.
