From: Tom Lane <tgl@sss.pgh.pa.us>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: Michael Stone <mstone+postgres@mathom.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: WAL sync behaviour
Date: Thu, 10 Nov 2005 11:39:34 -0500
Message-ID: <9791.1131640774@sss.pgh.pa.us> (raw)
In-Reply-To: <1131637958.3554.75.camel@state.g2switchworks.com>
References: <20051110133241.GA4031@uio.no>
<437355C6.4030604@archonet.com>
<20051110142535.GA4530@uio.no>
<20051110144309.GO9905@mathom.us>
<1131637958.3554.75.camel@state.g2switchworks.com>
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> On Thu, 2005-11-10 at 08:43, Michael Stone wrote:
>> There's no reason to use a journaled filesystem for the wal. Use ext2 in
>> preference to ext3.
> Not from what I understood. Ext2 can't guarantee that your data will
> even be there in any form after a crash. I believe only metadata
> journaling is needed though.
No, Mike is right: for WAL you shouldn't need any journaling. This is
because we zero out *and fsync* an entire WAL file before we ever
consider putting live WAL data in it. During live use of a WAL file,
its metadata is not changing. As long as the filesystem follows
the minimal rule of syncing metadata about a file when it fsyncs the
file, all the live WAL files should survive crashes OK.
We can afford to do this mainly because WAL files can normally be
recycled instead of created afresh, so the zero-out overhead doesn't
get paid during normal operation.
You do need metadata journaling for all non-WAL PG files, since we don't
fsync them every time we extend them; which means the filesystem could
lose track of which disk blocks belong to such a file, if it's not
journaled.
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, smarlowe@g2switchworks.com, mstone+postgres@mathom.us
Subject: Re: WAL sync behaviour
In-Reply-To: <9791.1131640774@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