From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgresql Hackers Mailinglist <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: spoonbill vs. -HEAD |
Date: | 2013-03-26 21:48:27 |
Message-ID: | 515217AB.3050609@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/26/2013 09:33 PM, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)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.
hmm - will look into that in a bit - but I also just noticed that on the
same day spoonbill broke there was also a commit to that file
immediately before that code adding the fflush() calls.
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-03-26 22:30:45 | Re: spoonbill vs. -HEAD |
Previous Message | Tom Lane | 2013-03-26 21:47:30 | Re: Ignore invalid indexes in pg_dump |