Re: psql lacking clearerr() - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: psql lacking clearerr()
Date
Msg-id 20210329210546.GA14244@alvherre.pgsql
Whole thread Raw
In response to Re: psql lacking clearerr()  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: psql lacking clearerr()
List 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@eisentraut.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@manitou-mail.org>
    Author: David Zhang <david.zhang@highgo.ca>
    Discussion: https://www.postgresql.org/message-id/flat/9a0b3c8d-ee14-4b1d-9d0a-2c993bdabacc@manitou-mail.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)



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Add client connection check during the execution of the query
Next
From: David Rowley
Date:
Subject: Re: Getting better results from valgrind leak tracking