Stefan Kaltenbrunner <ste...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
