Re: Making psql error out on output failures - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Making psql error out on output failures
Date
Msg-id 4e34f612-d504-4cfa-a28b-d30e3158803f@manitou-mail.org
Whole thread Raw
In response to Re: Making psql error out on output failures  (David Zhang <david.zhang@highgo.ca>)
Responses Re: Making psql error out on output failures  (David Zhang <david.zhang@highgo.ca>)
List 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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Collation versioning
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Physical replication slot advance is not persistent