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

Re: initdb and fsync

From: Noah Misch <noah(at)leadboat(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: initdb and fsync
Date: 2012-02-05 01:18:49
Message-ID: 20120205011849.GC24073@tornado.leadboat.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Feb 04, 2012 at 03:41:27PM -0800, Jeff Davis wrote:
> On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
> > Yeah.  Personally I would be sad if initdb got noticeably slower, and
> > I've never seen or heard of a failure that this would fix.
> 
> I worked up a patch, and it looks like it does about 6 file fsync's and
> a 7th for the PGDATA directory. That degrades the time from about 1.1s
> to 1.4s on my workstation.

> So, is it worth it? Should we make it an option that can be specified?

If we add fsync calls to the initdb process, they should cover the entire data
directory tree.  This patch syncs files that initdb.c writes, but we ought to
also sync files that bootstrap-mode backends had written.  An optimization
like the pg_flush_data() call in copy_file() may reduce the speed penalty.

initdb should do these syncs by default and offer an option to disable them.

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-05 01:47:05
Subject: Re: Review of: explain / allow collecting row counts without timing info
Previous:From: Tom LaneDate: 2012-02-05 00:30:35
Subject: Re: Patch: Allow SQL-language functions to reference parameters by parameter name

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