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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, 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:11:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
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.

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?

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Arjen van der MeijdenDate: 2010-02-14 17:12:00
Subject: Re: PostgreSQL on SMP Architectures
Previous:From: Reydan CankurDate: 2010-02-14 16:36:24
Subject: PostgreSQL on SMP Architectures

pgsql-hackers by date

Next:From: Ross J. ReedstromDate: 2010-02-14 17:17:42
Subject: Re: function to display ddl
Previous:From: Greg StarkDate: 2010-02-14 17:06:09
Subject: Re: Optimizing GetConflictingVirtualXIDs()

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