Re: psql lacking clearerr()

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(at)eisentraut(dot)org>, Daniel Verite <daniel(at)manitou-mail(dot)org>, David Zhang <david(dot)zhang(at)highgo(dot)ca>
Subject: Re: psql lacking clearerr()
Date: 2021-03-29 21:05:46
Message-ID: 20210329210546.GA14244@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Mar-25, Kyotaro Horiguchi wrote:

> That worked for me:p And the following steps always raises that error.
>
> postgres=# select 1; (just to let it into history).
> postgres=# C-s -> C-p -> C-m -> C-c
> postgres=# select 1;
> ...
> could not print result table: Success

Ah, thanks! Indeed this reliably reproduces the issue. I was very
surprised to find out that this bug is new in pg13. But then I bisected
it down to this commit:

commit b03436994bcc4909dd644fd5ae6d9a9acdf30da5
Author: Peter Eisentraut <peter(at)eisentraut(dot)org>
AuthorDate: Fri Mar 20 16:04:15 2020 +0100
CommitDate: Fri Mar 20 16:04:15 2020 +0100

psql: Catch and report errors while printing result table

Errors (for example I/O errors or disk full) while printing out result
tables were completely ignored, which could result in silently
truncated output in scripts, for example. Fix by adding some basic
error checking and reporting.

Author: Daniel Verite <daniel(at)manitou-mail(dot)org>
Author: David Zhang <david(dot)zhang(at)highgo(dot)ca>
Discussion: https://www.postgresql.org/message-id/flat/9a0b3c8d-ee14-4b1d-9d0a-2c993bdabacc(at)manitou-mail(dot)org

which is where this message was added. So it turns out that this has
*always* been a problem ... we just didn't know.

Due to lack of complaints, I'm inclined to apply this only back to pg13.

(And, yes, I'm to remove the %m too, because clearly that was a mistake.)

--
Álvaro Herrera 39°49'30"S 73°17'W
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended." (Gerry Pourwelle)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-03-29 21:18:11 Re: Getting better results from valgrind leak tracking
Previous Message Thomas Munro 2021-03-29 21:00:13 Re: Add client connection check during the execution of the query