Re: Disaster! - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Disaster!
Date
Msg-id 40130C19.2070903@familyhealth.com.au
Whole thread Raw
In response to Re: Disaster!  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Disaster!  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> After more staring at the code, I have a theory.  SlruPhysicalWritePage
> and SlruPhysicalReadPage are coded on the assumption that close() can
> never return any interesting failure.  However, it now occurs to me that
> there are some filesystem implementations wherein ENOSPC could be
> returned at close() rather than the preceding write().  (For instance,
> the HPUX man page for close() states that this never happens on local
> filesystems but can happen on NFS.)  So it'd be possible for
> SlruPhysicalWritePage to think it had successfully written a page when
> it hadn't.  This would allow a checkpoint to complete :-(

FreeBSD 4.7/4.9 and the UFS filesystem

RETURN VALUES     The close() function returns the value 0 if successful; otherwise the     value -1 is returned and
theglobal variable errno is set to 
 
indicate the     error.

ERRORS     Close() will fail if:
     [EBADF]            D is not an active descriptor.
     [EINTR]            An interrupt was received.


Chris


pgsql-hackers by date:

Previous
From: Richard Schilling
Date:
Subject: New Open Source License: Single Supplier Open Source License [rschi@rsmba.biz]
Next
From: Tom Lane
Date:
Subject: Re: Disaster!