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

Re: Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)postgresql(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-committers(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Date: 2010-02-22 14:53:59
Message-ID: 24404.1266850439@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Mon, Feb 22, 2010 at 2:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I also think it should scan the todir not the fromdir, just on
>> general principles to avoid any possibility of race conditions.

> I had concluded that scanning the original directory was odd but
> better because it served to double-check that all the original files
> actually made it and also because if there were any unrelated files
> present there was no need to fsync them.

Well, just for the record: if that was actually intentional then both of
you erred seriously by not including a comment that explained that the
coding was intentional (and giving the reasoning).  Any reader of the
code would have assumed that it was a copy-and-paste error, as I did.

> But I agree it's odd and not
> very general for copydir if we decide to use it elsewhere other than
> create database.

Yeah, to me it seems more likely to cause problems down the road than
to catch anything.  If the system is missing directory entries during
ReadDir then we have problems far beyond what copydir can deal with.
The point of the fsync loop is just to force the copy results down to
the platter, not to cross-check that the source directory isn't
changing.  (And, what's more, I don't believe that the source directory
can't change during CREATE DATABASE.  Consider delayed cleanup of
deleted relations during checkpoints.)

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-02-22 15:31:45
Subject: Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries
Previous:From: Robert HaasDate: 2010-02-22 14:46:36
Subject: ALTER TABLE documentation

pgsql-committers by date

Next:From: Tom LaneDate: 2010-02-22 15:26:15
Subject: pgsql: Adjust pg_fsync_writethrough so that it will set errno when
Previous:From: Heikki LinnakangasDate: 2010-02-22 11:47:30
Subject: pgsql: Move documentation of all recovery.conf option to a new chapter.

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