Skip site navigation (1) Skip section navigation (2)

Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Date: 2010-02-14 17:27:00
Message-ID: 201002141827.04993.andres@anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Sunday 14 February 2010 18:11:39 Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-02-14 17:37:15
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Previous:From: Arjen van der MeijdenDate: 2010-02-14 17:12:00
Subject: Re: PostgreSQL on SMP Architectures

pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-02-14 17:33:13
Subject: Re: psycopg2 license changed
Previous:From: Tom LaneDate: 2010-02-14 17:24:59
Subject: Re: knngist patch support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group