Re: BUG #13888: pg_dump write error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, kunschikov(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13888: pg_dump write error
Date: 2016-02-02 21:12:54
Message-ID: 19038.1454447574@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2016-02-02 21:56:33 Re: BUG #13888: pg_dump write error
Previous Message seth-p 2016-02-02 19:47:29 BUG #13908: Query returns too few rows