Re: psql - add SHOW_ALL_RESULTS option

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: psql - add SHOW_ALL_RESULTS option
Date: 2022-01-03 16:35:31
Message-ID: 46259d13-5f90-1475-3c85-d7a597a2b862@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23.12.21 12:40, Fabien COELHO wrote:
> 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.

With this "voluntary crash", the regression test output is now

psql ... ok (test process exited with
exit code 2) 281 ms

Normally, I'd expect this during development if there was a crash
somewhere, but showing this during a normal run now, and moreover still
saying "ok", is quite weird and confusing. Maybe this type of test
should be done in the TAP framework instead.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2022-01-03 16:36:53 Re: Index-only scans vs. partially-retrievable indexes
Previous Message Tom Lane 2022-01-03 16:34:36 Re: daitch_mokotoff module