Subject: Re: WAL sync behaviour
From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Stone <mstone+postgres@mathom.us>,
 pgsql-performance@postgresql.org
In-Reply-To: <9791.1131640774@sss.pgh.pa.us>
References: <20051110133241.GA4031@uio.no> <437355C6.4030604@archonet.com>
	<20051110142535.GA4530@uio.no> <20051110144309.GO9905@mathom.us>
	<1131637958.3554.75.camel@state.g2switchworks.com>
	<9791.1131640774@sss.pgh.pa.us>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1131642009.3554.87.camel@state.g2switchworks.com>
Mime-Version: 1.0
Date: Thu, 10 Nov 2005 11:00:10 -0600

On Thu, 2005-11-10 at 10:39, Tom Lane wrote:
> 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.

Thanks for the clarification!  Nice to know I can setup an ext2
partition for my WAL files then.  Is this in the docs anywhere?