> > I feel that the fact that
> > 
> > WAL can't help in the event of disk errors
> > 
> > is often overlooked.
> 
> This is true in general.  But, nevertheless, WAL can be written to
> protect against predictable disk errors, when possible.  Failing to
> write a couple of disk blocks when the system crashes is a reasonably
> predictable disk error.  WAL should ideally be written to work
> correctly in that situation.

But what can be done if fsync returns before pages flushed?

Vadim

Wed, 7 Mar 2001 12:03:41 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Proposed WAL changes
On Wed, 7 Mar 2001, Mikheev, Vadim wrote:

> But what can be done if fsync returns before pages flushed?
No, it won't. When fsync returns, data is promised by the OS to be on
disk.

-alex


Wed, 7 Mar 2001 16:06:50 -0500 (EST)
Alex Pilosov <alex@pilosoft.com>
RE: Proposed WAL changes
On Wed, Mar 07, 2001 at 12:03:41PM -0800, Mikheev, Vadim wrote:
> Ian wrote:
> > > I feel that the fact that
> > > 
> > > WAL can't help in the event of disk errors
> > > 
> > > is often overlooked.
> > 
> > This is true in general.  But, nevertheless, WAL can be written to
> > protect against predictable disk errors, when possible.  Failing to
> > write a couple of disk blocks when the system crashes 

or, more likely, when power drops; a system crash shouldn't keep the
disk from draining its buffers ...

> > is a reasonably predictable disk error.  WAL should ideally be 
> > written to work correctly in that situation.
> 
> But what can be done if fsync returns before pages flushed?

Just what Tom has done: preserve a little more history.  If it's not
too expensive, then it doesn't hurt you when running on sound hardware,
but it offers a good chance of preventing embarrassments for (the 
overwhelming fraction of) users on garbage hardware.

Nathan Myers
ncm@zembu.com

Wed, 7 Mar 2001 13:58:25 -0800
ncm@zembu.com (Nathan Myers)
Re: Proposed WAL changes
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:

> > > I feel that the fact that
> > > 
> > > WAL can't help in the event of disk errors
> > > 
> > > is often overlooked.
> > 
> > This is true in general.  But, nevertheless, WAL can be written to
> > protect against predictable disk errors, when possible.  Failing to
> > write a couple of disk blocks when the system crashes is a reasonably
> > predictable disk error.  WAL should ideally be written to work
> > correctly in that situation.
> 
> But what can be done if fsync returns before pages flushed?

When you write out critical information, you keep earlier versions of
it.  On startup, if the critical information is corrupt, you use the
earlier versions of it.  This helps protect against the scenario I
mentioned: a few disk blocks may not have been written when the power
goes out.

My impression is that that is what Tom is doing with his patches.

Ian

---------------------------(end of broadcast)---------------------------
TIP 77: A beautiful man is paradise for the eyes, hell for the soul, and
purgatory for the purse.

07 Mar 2001 16:23:33 -0800
Ian Lance Taylor <ian@airs.com>
Re: Proposed WAL changes