Michael Stone <mstone+postgres@mathom.us> writes:
> On Sat, Aug 20, 2005 at 02:17:54PM +0300, Marko Ristola wrote:
>> Based on my knoledge, Ext3 is good with keeping filesystem integrity
>> AND data integrity while pressing the reset button. However, by
>> selecting data=writeback, you gain more speed, but you risk the data
>> integrity during a crash: Ext3 garantees only filesystem integrity.
> That's why postgres keeps its own transaction log. Any of these
> filesystems guarantee data integrity for data that's been synced to
> disk, and postgres keeps track of what data has and has not been
> committed so it can recover gracefully from a failure.
Right. I think the optimal setting for a Postgres data directory is
journaled metadata, non-journaled file content. Postgres can take care
of the data integrity for itself, but it does assume that the filesystem
stays structurally sane (eg, data blocks don't get reassigned to the
wrong file), so you need a filesystem guarantee about the metadata.
WAL files are handled in a much more conservative way (created, filled
with zeroes, and fsync'd before we ever put any valuable data in 'em).
If you have WAL on its own drive then I think Mike's recommendation of
no filesystem journalling at all for that drive is probably OK. Or
you can do same as above (journal metadata only) if you want a little
extra protection.
And of course all this reasoning depends on the assumption that the
drive tells the truth about write-completion. If the drive does write
caching it had better be able to complete all its accepted writes before
dying in a power failure. (Hence, battery-backed write cache is OK, any
other kind is evil.)
regards, tom lane
