"Tom Lane" <[EMAIL PROTECTED]> 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
