Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> As I've said before, I think we need to find a way to stop using sync()
> >> altogether --- we have to move to fsync or O_SYNC and variants. sync
> >> has simply got the wrong API.
>
> > If sync failes (kernel to disk write failes) we have a hardware failure,
> > and we don't pretend to recover from that,
>
> Not necessarily --- it could be out-of-disk-space, on at least some
> filesystems. More to the point, the important thing is not to commit a
I assume the operating system is already allocating file system space
during the write, and the sync is only forcing it to disk. If the
operating system doesn't allocate file system space it couldn't properly
work, no? In fact, it is my understanding that the file system is in
RAM and the disk is just backing store, basically.
> checkpoint record to WAL indicating that everything is good, when
> everything is not good. As long as we don't checkpoint we have some
> hope of recovering automatically via WAL replay.
>
> > One idea I floated around was to
> > open/write/fsync/close a temporary file after sync in the hope that it
> > would happen after the sync completes because the fsync would be at the
> > end of the disk flush queue.
>
> "In the hope"? We already have a guess-and-hope approach to this, and
> it will never be any better as long as we use sync(), because sync() is
> fundamentally the wrong operation. It doesn't tell you when the I/O is
> done, and it doesn't tell you whether the I/O was done successfully, and
> there is no possibility of working around that fundamental lack of
> information except to stop using it.
I assumed this would be a closer guess-and-hope approach, and again, how
could sync fail unless it is a hardware problem? NFS?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
