Skip site navigation (1) Skip section navigation (2)

Re: Testing the return value of fclose() in the backend

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing the return value of fclose() in the backend
Date: 2003-05-31 03:06:15
Message-ID: Pine.LNX.4.21.0305311300230.13303-100000@linuxworld.com.au (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 30 May 2003, Bruce Momjian wrote:

> Gavin Sherry wrote:
> > Hi all,
> > 
> > There are various places in the backend, such as FreeFile(), where the
> > return value of fclose() is not tested. Whilst we would often notice any
> > problems with writing to data files due to testing on fsync(), it could
> > affect things like COPY ... TO, CreateOptsFile() and more.
> > 
> > Are we catching these somewhere else I'm not seeing?
> 
> We are not checking fclose, probably because fclose failures are quite
> rare.  Should we be concerned?

fsync() errors are probably just as rare. The problem with long running
daemons not testing for fclose() failure is the problem caused by file
descriptor leakage. I recall that squid (another long running daemon) had
this problem due to the large number of file systems interactions they
undertake. The question is, of course, what to do in postgres if
fclose() returns an error? elog(WARNING)? Another fclose() call? Not sure
what squid did.

Gavin


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-05-31 03:07:00
Subject: Re: [HACKERS] Are we losing momentum?
Previous:From: Bruce MomjianDate: 2003-05-31 02:54:35
Subject: Re: Testing the return value of fclose() in the backend

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group