From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Recovery of PGSQL after system crash failing!!! |
Date: | 2001-02-14 01:09:15 |
Message-ID: | 3A89DABB.19B030FA@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Guilty as charged I am afraind... :( Here, I though with WAL and
> all (bad pun :), I would not need fsync anymore and decided to be
> reckless. Guess I ought to reconsider that decision.... Though wasn't WAL
> supposed to remove the need for fsync, or was it just to improve recovery
> ablity?
It removes the need to disable fsync to get best performance! The
converse is not true; it does not eliminate the need to fsync to help
guard data integrity, and the WAL file management may be a bit less
robust than that for other tables. I can see how this might have been
omitted from much of the discussion, so it is important that we remind
ourselves about this. Thanks for the reminder :/
Since there is a fundamental recovery problem if the WAL file
disappears, then perhaps we should have a workaround which can ignore
the requirement for that file on startup? Or maybe we do already?
Vadim??
Also, could the "-F" option be disabled now that WAL is enabled? Or is
there still some reason to encourage/allow folks to use it?
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Ryan Kirkpatrick | 2001-02-14 01:31:04 | RE: Recovery of PGSQL after system crash failing!!! |
Previous Message | Tom Lane | 2001-02-14 00:10:46 | Re: NEW and OLD in EXECUTE |