Re: psql - add SHOW_ALL_RESULTS option

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
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: 2021-12-23 11:40:37
Message-ID: alpine.DEB.2.22.394.2112230703530.2668598@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Peter,

I finally took some time to look at this.

>> Attached v11 is a rebase.
>
> This patch still has a few of the problems reported earlier this year.
>
> 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.

Attached v12 somehow fixes these issues in "psql" code rather than in
libpq.

--
Fabien.

Attachment Content-Type Size
psql-show-all-results-12.patch text/x-diff 49.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 曾文旌 (义从) 2021-12-23 11:52:05 回复:回复:Re: Re: 回复:Re: Is it worth pushing conditions to sublink/subplan?
Previous Message Bharath Rupireddy 2021-12-23 11:39:28 correct the sizes of values and nulls arrays in pg_control_checkpoint