Re: psql - add SHOW_ALL_RESULTS option
От | Peter Eisentraut |
---|---|
Тема | Re: psql - add SHOW_ALL_RESULTS option |
Дата | |
Msg-id | 10906444-d995-0a34-bb22-faf6d9f07f92@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: psql - add SHOW_ALL_RESULTS option (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: psql - add SHOW_ALL_RESULTS option
|
Список | pgsql-hackers |
On 23.12.21 12:40, Fabien COELHO wrote: >> In [0], it was reported that certain replication commands result in >> infinite loops because of faulty error handling. This still happens. >> I wrote a test for it, attached here. (I threw in a few more basic >> tests, just to have some more coverage that was lacking, and to have a >> file to put the new test in.) > > Hmmm… For some unclear reason on errors on a PGRES_COPY_* state > PQgetResult keeps on returning an empty result. PQexec manually ignores > it, so I did the same with a comment, but for me the real bug is somehow > in PQgetResult behavior… > >> In [1], it was reported that server crashes produce duplicate error >> messages. This also still happens. I didn't write a test for it, >> maybe you have an idea. (Obviously, we could check whether the error >> message is literally there twice in the output, but that doesn't seem >> very general.) But it's easy to test manually: just have psql >> connect, shut down the server, then run a query. > > This is also a feature/bug of libpq which happens to be hidden by > PQexec: when one command crashes PQgetResult actually returns *2* > results. First one with the FATAL message, second one when libpq figures > out that the connection was lost with the second message appended to the > first. PQexec just happen to silently ignore the first result. I added a > manual reset of the error message when first shown so that it is not > shown twice. It is unclear to me whether the reset should be somewhere > in libpq instead. I added a voluntary crash at the end of the psql test. I agree that these two behaviors in libpq are dubious, especially the second one. I want to spend some time analyzing this more and see if fixes in libpq might be appropriate.
В списке pgsql-hackers по дате отправления: