Thread: Should psql exit when the log file can't be written into?

  Hi,

Following last week's commit 344cdff :

Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:    Thu Dec 3 14:28:58 2015 -0500

    Clean up some psql issues around handling of the query output file.

    Formerly, if "psql -o foo" failed to open the output file "foo", it would
    print an error message but then carry on as though -o had not been
    specified at all.  This seems contrary to expectation: a program that
    cannot open its output file normally fails altogether.  Make psql do
    exit(1) after reporting the error.
    [...]

I notice that --log-file also reports an error but continues nonetheless
if the file can't be opened.
The attached trivial patch makes it fail and exit instead.

Also there's the fact that once opened, psql currently ignores errors
when writing to that file.

Without going as far as tracking every write in print.c,  there are at
least two places in the code where it would be easy to abort the
processing, should we want to, at the beginning of SendQuery() and
PSQLexec(). The code here looks like:

  if (pset.logfile)
  {
    fprintf(pset.logfile,
    _("********* QUERY **********\n"
      "%s\n"
      "**************************\n\n"), query);
    fflush(pset.logfile);
  }

At this point if fprintf() returns a negative value, maybe we should
error out and exit rather than ignore it.
Or at least do that when ON_ERROR_STOP is on?

The typical case when it might happen is a disk full condition.
In this scenario, I can imagine a psql exit(1) being both desirable
or not. Certain users could be satisfied that a script went to completion
even in this client-side degraded state.
But other users could be unhappy about the queries being executed
without leaving the expected traces, if the logging part happens to
be essential to them.


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

"Daniel Verite" <daniel@manitou-mail.org> writes:
> I notice that --log-file also reports an error but continues nonetheless
> if the file can't be opened.
> The attached trivial patch makes it fail and exit instead.

I agree with doing that.

> Also there's the fact that once opened, psql currently ignores errors
> when writing to that file.
> Without going as far as tracking every write in print.c,  there are at
> least two places in the code where it would be easy to abort the
> processing, should we want to, at the beginning of SendQuery() and
> PSQLexec().

I do not think this is a good approach.  Disk-full conditions, as an
example, are quite likely to appear and disappear over the course of
a run, if other programs are creating/deleting files.  Thus we might
lose some log output and never notice, if we only test for errors
here and there.  Providing partial coverage would then provide users
with a false sense of confidence that their log isn't truncated.

(It might work to check ferror() every so often, instead of checking
results for individual output calls, but I'm not sure if all the
functions we use will set ferror().)

I'm lukewarm about whether psql should complain about I/O errors other
than open failure, but I think if we do it, it needs to be full
coverage.
        regards, tom lane