> A checkpoint would also have reason to wait for a page-level lock, if
> the stuck backend was holding one. I am wondering though if the stuck
> condition consistently happens while trying to fire a trigger? That
> would be very interesting ... not sure what it'd mean though ...
Hmm. I'm really at a loss as to how I could test this theory. I don't have
a truly reproducible test case for any of these syslog problems, just one
set of code with really bad luck one afternoon. Race conditions (or things
that smell a lot like them) stink.
> It looks to me like your plpython code is all dead in the water, seeing
> that your Python installation is refusing creation of rexec. (AFAIK the
> only workaround is to downgrade Python to a version that allows rexec.)
> If you're using it all over the place, how come you haven't noticed
> that??
I did notice, and it was an oversight. I had just rebuilt Python 2.2.3
(for unrelated reasons) and forgot to comment out the poision line in
rexec.py where they raise the "stop using RExec" exception. It behaves
properly once that line is commented out (properly being it works same as
with earlier versions of Python; it appears all that changed was the
insertion of the exception at the beginning of the RExec constructor). I
tried to get the deadlock behavior again after fixing rexec.py, but my
luck wasn't bad enough for another three runs, so I posted the case I had
traces for.
An idea just popped into my head, though. Perhaps I can create procedures
in plpgsql and plpython which do nothing but spew notices (which would in
turn be sent to syslog), and run one or two copies to see if they'll die
on their own given sufficient time. That seems worthwhile, especially if I
can get a deadlock in plpgsql, since it will take the blame away from both
triggers and plpython. Does this sound like a reasonable experiment? I may
try setting this up on my home machine tonight to run for a few days.