Re: BUG #13888: pg_dump write error
От | Tom Lane |
---|---|
Тема | Re: BUG #13888: pg_dump write error |
Дата | |
Msg-id | 19038.1454447574@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #13888: pg_dump write error (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BUG #13888: pg_dump write error
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: