Re: Making psql error out on output failures

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "David Zhang" <david(dot)zhang(at)highgo(dot)ca>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Making psql error out on output failures
Date: 2020-01-28 12:14:09
Message-ID: 4e34f612-d504-4cfa-a28b-d30e3158803f@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Zhang wrote:

> The error "No space left on device" can be logged by fprintf() which is
> redefined as pg_fprintf() when print_aligned_text() is called

Are you sure? I don't find that redefinition. Besides
print_aligned_text() also calls putc and puts.

> Will that be a better solution if redefine fputs similar to fprintf and
> log the exact error when first time discovered?

I think we can assume it's not acceptable to have pg_fprintf()
to print anything to stderr, or to set a flag through a global
variable. So even if using pg_fprintf() for all the printing, no matter
how (through #defines or otherwise), there's still the problem that the
error needs to be propagated up the call chain to be processed by psql.

> The concern is that if we can't provide a more accurate
> information to the end user when error happens, sometimes the
> end user might got even confused.

It's better to have a more informative message, but I'm for
not having the best be the enemy of the good.
The first concern is that at the moment, we have no error
report at all in the case when the output can be opened
but the error happens later along the writes.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-01-28 12:14:34 Re: Physical replication slot advance is not persistent
Previous Message Peter Eisentraut 2020-01-28 12:06:06 Re: Collation versioning