Re: Recent buildfarm failures involving statement_timeout - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Recent buildfarm failures involving statement_timeout
Date
Msg-id 87hcdnml82.fsf@oxford.xeocode.com
Whole thread Raw
In response to Recent buildfarm failures involving statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Recent buildfarm failures involving statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Another theory is that we broke something recently, but I see no obvious
> candidates in the CVS logs --- and I've spent the evening running 488
> cycles of the parallel regression tests here, with no error.

It looks to me like a psql bug rather than a server bug. Psql has some hairy
logic to try to remember whether it has handled an error return yet or not and
I had a devil of a time trying to keep it working with the concurrent psql
patch. One of the failure modes I saw a lot was handling an error twice like
this.

It's possible it's a race condition where it only happens if psql gets the
error at a certain point, such as while fetching the results as opposed to
while the execute is pending. However IIRC the logic without concurrent psql
is actually fairly straightforward and there are no windows like this. Unless
it's actually in libpq and not psql. Hm.

Perhaps Bruce's terminate patch wasn't completely reverted and there was a
flag somewhere which isn't being reset properly?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


pgsql-hackers by date:

Previous
From: Shane Ambler
Date:
Subject: Re: we don't have a bugzilla
Next
From: Andrew Dunstan
Date:
Subject: Re: Recent buildfarm failures involving statement_timeout