From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Stone <mstone+postgres@mathom.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: extremly low memory usage
Date: Sat, 20 Aug 2005 10:40:41 -0400
Message-ID: <23044.1124548841@sss.pgh.pa.us> (raw)
In-Reply-To: <20050820122305.GN19080@mathom.us>
References: <EA4219B9-E2B0-4756-ABF2-D84F245FDFB5@torgo.978.org>
<1124386761.27881.119.camel@bluejay.goodinassociates.com>
<4304CB77.4070403@arbash-meinel.com>
<1124470109.27881.152.camel@bluejay.goodinassociates.com>
<43061472.2080201@arbash-meinel.com>
<6.2.3.4.0.20050819140714.05c181e8@pop.earthlink.net>
<43063196.9000001@arbash-meinel.com>
<1124485299.27881.192.camel@bluejay.goodinassociates.com>
<EFA54B85-504E-453A-972D-A7DD0E144763@drivefaster.net>
<43071162.6050405@kolumbus.fi>
<20050820122305.GN19080@mathom.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, mstone+postgres@mathom.us
Subject: Re: extremly low memory usage
In-Reply-To: <23044.1124548841@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox