Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> On 03/26/2013 08:45 PM, Tom Lane wrote:
>> It looks from here like the isolationtester client is what's dropping
>> the ball --- the backend states are unsurprising, and two of them are
>> waiting for a new client command. Can you get a stack trace from the
>> isolationtester process?
> https://www.kaltenbrunner.cc/files/isolationtester.txt
Hmm ... isolationtester.c:584 is in the code that tries to cancel the
current permutation (test case) after realizing that it's constructed
an invalid permutation. It looks like the preceding PQcancel() failed
for some reason, since the waiting backend is still waiting. The
isolationtester code doesn't bother to check for an error result there,
which is kinda bad, not that it's clear what it could do about it.
Could you look at the contents of the local variable "buf" in the
run_permutation stack frame? Or else try modifying the code along the
lines of
- PQcancel(cancel, buf, sizeof(buf));
+ if (!PQcancel(cancel, buf, sizeof(buf)))
+ fprintf(stderr, "PQcancel failed: %s\n", buf);
and see if it prints anything interesting before hanging up.
regards, tom lane