Re: Recent buildfarm failures involving statement_timeout

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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!