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

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

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Date: 2010-02-28 18:00:07
Message-ID: 407d949e1002281000q648770eegff28a44fd0cb1751@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Tue, Feb 23, 2010 at 3:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The plan I was thinking of was to pass a flag indicating if it's a
>> directory to fsync_fname() and open it RD_ONLY if it's a directory and
>> RDRW if it's a file. Then ignore any error returns (or at least EBADF
>> and EINVAL) iff the flag indicating it was a directory was true.
>
> Works for me, but let's first try just ignoring EBADF, which is the only
> value we saw in the recent buildfarm failures.  If we got past the fd<0
> test then EBADF could only indicate a rdonly failure, whereas it's less
> clear what EINVAL might cover.

So I'm thinking of something like this.
Ignore ESDIR when opening a directory (and return immediately)
and ignore EBADF when trying to fsync a directory.


-- 
greg

Attachment: create-database-fsync-dirs-context.diff
Description: text/x-patch (2.9 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-28 19:25:57
Subject: Simple fix for contrib/xml2
Previous:From: Joachim WielandDate: 2010-02-28 15:56:28
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration

pgsql-committers by date

Next:From: Tom LaneDate: 2010-02-28 19:31:00
Subject: Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Previous:From: Bruce MomjianDate: 2010-02-28 02:20:40
Subject: pgsql: Update complex locale example in the documentation.

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