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
|
Список | 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 по дате отправления: