Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> I do not understand these claims that there isn't an error check there.
>> There surely is. But fwrite() didn't set errno.
> Yeah, that's what I was remembering actually:
> http://www.postgresql.org/message-id/20150608174336.GM133018@postgresql.org
>> The real question is why did he get a short write in the first place.
>> We don't make any attempt to support filesystems that require retries,
>> which seems to be what is going on here. Should we?
> Sounds likely.
Actually, now that I think about it while not in an airport, what I
think we really need is logic along the lines of
errno = 0;
nbytes = fwrite(...);
if (nbytes != expected && errno == 0)
errno = ENOSPC;
ie, assume a short write implies out-of-disk-space. I believe that
is what we do in most (hopefully all) cases in the backend; see for
example UpdateControlFile() in xlog.c.
IMO it is not really WRITE_ERROR_EXIT's place to assume that errno == 0
should be replaced by ENOSPC; in particular, that would be incorrect,
or at least insufficient, unless there's an explicit initialization of
"errno = 0;" before the fwrite call. So I'm inclined to put the
responsibility to do all of the above logic on the fwrite call sites,
rather than splitting it between callers and WRITE_ERROR_EXIT.
regards, tom lane
