Re: Recent buildfarm failures involving statement_timeout

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Recent buildfarm failures involving statement_timeout
Дата
Msg-id 87hcdnml82.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Recent buildfarm failures involving statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Recent buildfarm failures involving statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Shane Ambler
Дата:
Сообщение: Re: we don't have a bugzilla
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Recent buildfarm failures involving statement_timeout