Re: Disaster! - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Disaster!
Date
Msg-id 3813.1074966763@sss.pgh.pa.us
Whole thread Raw
In response to Re: Disaster!  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Disaster!  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: Disaster!  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
I said:
> If there wasn't disk space enough to hold the clog page, the checkpoint
> attempt should have failed.  So it may be that allowing a short read in
> slru.c would be patching the symptom of a bug that is really elsewhere.

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 :-(

Chris, what's your platform exactly, and what kind of filesystem are
you storing pg_clog on?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Disaster!
Next
From: Peter Eisentraut
Date:
Subject: Re: cvsignore