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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Mike Mascari
Дата:
Сообщение: A few notes
Следующее
От: "Anton V. Kozub"
Дата:
Сообщение: REMOVE