> > 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.

If fsync may return before data *actually* flushed then you may have
unlogged data page changes which breakes WAL rule and means corrupted
(inconsistent) database without ANY ABILITY TO RECOVERY TO CONSISTENT
STATE. Now please explain me how saving positions of two checkpoints
(what Tom is doing) can help here?

Vadim

Wed, 7 Mar 2001 17:49:34 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Proposed WAL changes
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> If fsync may return before data *actually* flushed then you may have
> unlogged data page changes which breakes WAL rule and means corrupted
> (inconsistent) database without ANY ABILITY TO RECOVERY TO CONSISTENT
> STATE. Now please explain me how saving positions of two checkpoints
> (what Tom is doing) can help here?

If the WAL log is broken then there is (AFAICT) no way to *guarantee*
recovery to a consistent state.  There might be changes in heap or index
pages that you cannot find a trace of in the readable part of the log,
and hence don't know you need to fix.

However, I think that Vadim is focusing too narrowly on what he can
guarantee, and neglecting the problem of providing reasonable behavior
when things are too broken to meet the guarantee.  In particular,
complete refusal to start up when the WAL log is corrupted is not
reasonable nor acceptable.  We have to be able to recover from that
and provide access to as-close-to-accurate data as we can manage.
I believe that backing up to the prior checkpoint and replaying as much
of the log as we can read is a useful fallback capability if the most
recent checkpoint record is unreadable.

In any case, "guarantees" that are based on the assumption that WAL
writes hit the disk before data writes do are going to fail anyway
if we are using disk drives that reorder writes.  This is the real
reason why we can't think only about guarantees, but also about how
we will respond to "guaranteed impossible" failures.

If you can improve on this recovery idea, by all means do so.  But
don't tell me that we don't need to worry about it, because we do.

			regards, tom lane

Wed, 07 Mar 2001 21:24:50 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposed WAL changes 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:

> If fsync may return before data *actually* flushed then you may have
> unlogged data page changes which breakes WAL rule and means corrupted
> (inconsistent) database without ANY ABILITY TO RECOVERY TO CONSISTENT
> STATE. Now please explain me how saving positions of two checkpoints
> (what Tom is doing) can help here?

Maybe it can't.  I don't know.

I do know that a system which can only function if all disk writes
complete in order is doomed when run on a Unix system with modern IDE
disks.  It won't work correctly in the case of a sudden power outage.

Since many people run Postgres in just that sort of environment, it's
not a good idea to completely fail to handle it.  Clearly a sudden
power outage can cause disk data to be corrupted.  People can accept
that.  They need to know what to do in that case.

For example, for typical Unix filesystems, after a sudden power
outage, people run fsck.  fsck puts the filesystem back in shape.  In
the process, it may find some files it can not fix; they are put in
/lost+found.  In the process, it may lose some files entirely; too
bad.  The point is, after fsck is run, the filesystem is known to be
good, and in most cases all the data will still be present.

Imagine if every time the power went out, people were required to
restore their disks from the last backup.

So, I think that what Postgres needs to do when it sees corruption is
just what fsck does: warn the user, put the database in a usable
state, and provide whatever information can be provided about lost or
inconsistent data.  Users who need full bore gold plated consistency
will restore from their last good backup, and invest in a larger UPS.
Many users will simply keep going.

Ian

---------------------------(end of broadcast)---------------------------
TIP 43: The human animal differs from the lesser primates in his passion for
lists of "Ten Best".
		-- H. Allen Smith

07 Mar 2001 21:52:00 -0800
Ian Lance Taylor <ian@airs.com>
Re: Proposed WAL changes
What do we debate?
I never told that we shouldn't worry about current WAL disability to restart.
And WAL already correctly works in situation of "failing to write a couple of disk
blocks when the system crashes".
My statement at first place that "WAL can't help in the event of disk errors"
was to remind that we should think over how much are we going to guarantee
and by what means in the event our *base* requirements were not answered
(guaranteed -:)). My POV is that two checkpoints increases disk space
requirements for *everyday usage* while buying near nothing because of data
consistency cannot be guaranteed anyway.
On the other hand this is the fastest way to implement WAL restart-ability
- *which is the real problem we have to fix*.

Vadim



Thu, 8 Mar 2001 04:24:23 -0800
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: Proposed WAL changes