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

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Date
Msg-id 1266228170.2079.2.camel@localhost.localdomain
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after  (marcin mank <marcin.mank@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
List pgsql-hackers
Hi Marcin,

Sounds rather unlikely to me. Its likely handled at an upper layer (vfs in linux' case) and only overloaded when an
optimizedimplementation is available.
 
Which os do you see implementing that only on a part of the filesystems?

A runtime check would be creating, fsyncing and deleting a directory for every directory youre fsyncing because they
couldbe on a different fs...
 

Andres
--
Sent from a mobile phone - please excuse brevity and formatting.
----- Ursprüngliche Mitteilung -----
> On Mon, Feb 15, 2010 at 9:36 AM, Andres Freund <andres@anarazel.de> wrote:
> > On Monday 15 February 2010 08:13:32 Tom Lane wrote:
> > > Actually, looking closer, some of the Windows machines started failing
> > > after the *earlier* patch to add directory fsyncs.
> > And not only the windows machines. Seems sensible to add a configure check
> > whether directory-fsyncing works.
>
> It looks like a thing that can be filesystem-dependent. Maybe a kind
> of runtime check?
>
> Greetings
> Marcin Mańk
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Next
From: Fujii Masao
Date:
Subject: Re: TCP keepalive support for libpq