From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql-server/src backend/storage/buffer/bufmgr ... |
Date: | 2004-01-26 20:44:38 |
Message-ID: | 200401262044.i0QKicp05990@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> 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.
>
> Not so --- as was pointed out later in the thread, neither NFS nor AFS
> work that way, and there could be other cases.
>
> In any case, I don't subscribe to the idea that we can just abdicate all
> responsibility in case of hardware problems. Yes, we do rely on a disk
> to keep storing information once it's accepted it, but that doesn't mean
> that it's okay to ignore write-failure reports. We are failing to hold
> up our end of the deal if we do that.
Well, in normal usage, applications do the write and expect the data to
be pushed to disk later, so I don't see us ignoring write() failures,
but rather push to disk. Isn't a separate fsync after sync closer to
reliable?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-01-26 22:13:21 | pgsql-server/doc/src/sgml libpq.sgml |
Previous Message | Tom Lane | 2004-01-26 20:17:38 | Re: pgsql-server/src backend/storage/buffer/bufmgr ... |