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

Re: initdb and fsync

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: initdb and fsync
Date: 2012-01-28 18:46:06
Message-ID: 1327776366.1734.39.camel@jdavis (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > I'm curious what problem we're actually solving here, though. I've run 
> > the buildfarm countless thousands of times on different VMs, and five of 
> > my seven current animals run in VMs, and I don't think I've ever seen a 
> > failure ascribable to inadequately synced files from initdb.
> 
> 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 wonder whether it wouldn't be sufficient to call sync(2) at the end,
> anyway, rather than cluttering the entire initdb codebase with fsync
> calls.

I can always add a "sync" call to the test, also (rather than modifying
initdb). Or, it could be an initdb option, which might be a good
compromise. I don't have a strong opinion here.

As machines get more memory and filesystems get more lazy, I wonder if
it will be a more frequent occurrence, however. On the other hand, if
filesystems are more lazy, that also increases the cost associated with
extra "sync" calls. I think there would be a surprise factor if
sometimes initdb had a long pause at the end and caused 10GB of data to
be written out.

Regards,
	Jeff Davis


In response to

Responses

pgsql-hackers by date

Next:From: Kohei KaiGaiDate: 2012-01-28 18:53:08
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Previous:From: Jeff JanesDate: 2012-01-28 18:27:14
Subject: Re: initdb and fsync

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