"Daniel Verite" <dan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
