From: Jim C. Nasby <jnasby@pervasive.com>
To: pgsql-performance@postgresql.org
Subject: Re: Migration study, step 1: bulk write performance
Date: Tue, 21 Mar 2006 06:45:25 -0600
Message-ID: <20060321124525.GX15742@pervasive.com> (raw)
In-Reply-To: <20060321122954.GB13241@uio.no>
References: <7F10D26ECFA1FB458B89C5B4B0D72C2B088286@sesrv12.wirelesscar.com>
<1142867952.16487.96.camel@coppola.muc.ecircle.de>
<20060321112759.GF15742@pervasive.com>
<1142941966.23597.4.camel@coppola.muc.ecircle.de>
<20060321115618.GA12880@uio.no>
<20060321120158.GO15742@pervasive.com>
<20060321121032.GB12963@uio.no>
<20060321121839.GT15742@pervasive.com>
<20060321122954.GB13241@uio.no>
On Tue, Mar 21, 2006 at 01:29:54PM +0100, Steinar H. Gunderson wrote:
> On Tue, Mar 21, 2006 at 06:18:39AM -0600, Jim C. Nasby wrote:
> > Basically, you need to know for certain that if PostgreSQL creates a
> > file and then fsync's it that that file is safely on disk, and that the
> > filesystem knows how to find it (ie: the metadata is also on disk in
> > some fashion).
>
> It seems to do, quoting Tom from
> http://archives.postgresql.org/pgsql-performance/2005-11/msg00184.php:
404 :(
>
> == snip ==
> 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.
And therin lies the rub: file metadata *must* commit to disk as part of
an fsync, and it's needed for both WAL and heap data. It's needed for
heap data because as soon as a checkpoint completes, PostgreSQL is free
to erase any WAL info about previous DDL changes.
On FreeBSD, if you're using softupdates, the filesystem will properly
order writes to the drive so that metadata must be written before file
data; this ensures that an fsync on the file will first write any
metadata before writing the data itself.
With fsync turned off, any metadata-changing commands will wait for the
metadata to commit to disk before returning (unless you run async...)
I'm not really sure how this all plays out on a journalling filesystem.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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: jnasby@pervasive.com
Subject: Re: Migration study, step 1: bulk write performance
In-Reply-To: <20060321124525.GX15742@pervasive.com>
* 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