From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Testing the return value of fclose() in the backend |
Date: | 2003-05-31 04:55:11 |
Message-ID: | Pine.LNX.4.21.0305311451140.27434-100000@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 30 May 2003, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2003-05-31 07:39:34 | Re: [GENERAL] Are we losing momentum? |
Previous Message | Mike Mascari | 2003-05-31 04:40:09 | A few notes |