Re: Testing the return value of fclose() in the backend
От | Gavin Sherry |
---|---|
Тема | Re: Testing the return value of fclose() in the backend |
Дата | |
Msg-id | Pine.LNX.4.21.0305311451140.27434-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: Testing the return value of fclose() in the backend (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Testing the return value of fclose() in the backend
|
Список | pgsql-hackers |
On Fri, 30 May 2003, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Gavin Sherry wrote: > >> There are various places in the backend, such as FreeFile(), where the > >> return value of fclose() is not tested. > > > We are not checking fclose, probably because fclose failures are quite > > rare. Should we be concerned? > > Probably. Closing a valid file descriptor in itself can't provoke any > error that I can imagine, but fclose() also implies fflush() --- so if > you have written data that hasn't yet been forced out of the stdio > buffers then out-of-disk-space is certainly a foreseeable failure. Yes. I think I brought that up in my original email. Heap access/WAL routines 'should not' suffer an fclose() problem because of fsync() calls. But this isn't necessarily the case for COPY. > > fclose failure on an open-for-read-only file seems like Assert() > material; it "can't happen". Right. If this generates an error, there are probably more serious issues. Gavin
В списке pgsql-hackers по дате отправления: