From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu
	karmic slow createdb)
Date: Sun, 14 Feb 2010 18:27:00 +0100
User-Agent: KMail/1.13.0 (Linux/2.6.33-rc7-andres-00124-g828206f; KDE/4.4.0;
	x86_64; ; )
Cc: Greg Stark <gsstark@mit.edu>, Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@postgresql.org
References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com>
	<407d949e1002140731j85a4f97nc053ec1b0f3cc458@mail.gmail.com>
	<22295.1266167499@sss.pgh.pa.us>
In-Reply-To: <22295.1266167499@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201002141827.04993.andres@anarazel.de>

On Sunday 14 February 2010 18:11:39 Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > So I think we have a bigger problem than just copydir.c. It seems to
> > me we should be fsyncing the table space data directories on every
> > checkpoint.
> 
> Is there any evidence that anyone anywhere has ever lost data because
> of a lack of directory fsyncs?  I sure don't recall any bug reports
> that seem to match that theory.
I have actually seen the issue during create database at least. In a 
virtualized hw though...
~1GB template database, lots and lots of small tables, the crash occured maybe 
a minute after CREATE DB, filesystem was xfs, kernel 2.6.30.y.
 
> It seems to me that we're talking about a huge hit in both code
> complexity and performance to deal with a problem that doesn't actually
> occur in the field; and which furthermore is trivially solved on any
> modern filesystem by choosing the right filesystem options.  Why don't
> we just document those options, instead?
Which options would that be? I am not aware that there any for any of the 
recent linux filesystems.
Well, except "sync" that is, but that sure would be more of a performance hit 
than fsyncing the directory...

Andres