From: Jim C. Nasby <jnasby@pervasive.com>
To: Csaba Nagy <nagy@ecircle-ag.com>
To: Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
To: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Migration study, step 1: bulk write performance
Date: Tue, 21 Mar 2006 06:18:39 -0600
Message-ID: <20060321121839.GT15742@pervasive.com> (raw)
In-Reply-To: <20060321121032.GB12963@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>
On Tue, Mar 21, 2006 at 01:10:32PM +0100, Steinar H. Gunderson wrote:
> On Tue, Mar 21, 2006 at 06:01:58AM -0600, Jim C. Nasby wrote:
> > Are you sure? Metadate changes are probably a lot more common on the WAL
> > partition. In any case, I don't see why there should be a difference.
> > The real issue is: is related filesystem metadata sync'd as part of a
> > file being fsync'd?
>
> I've been told on this list that PostgreSQL actually takes care to fill a new
> WAL file with zeroes etc. when initializing it; dig a few months back and I'm
> sure it's there.
That's fine and all, but does no good if the filesystem doesn't know
that the file exists on a crash. The same concern is also true on the
data partition, although it's less likely to be a problem because if you
happen to crash soon after a DDL operation it's likely that you haven't
had a checkpoint yet, so the operation will likely be repeated during
WAL replay. But depending on that is a race condition.
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).
--
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, nagy@ecircle-ag.com, Mikael.Carneholm@WirelessCar.com
Subject: Re: Migration study, step 1: bulk write performance
In-Reply-To: <20060321121839.GT15742@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