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