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

Re: initdb and fsync

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: initdb and fsync
Date: 2012-01-28 18:59:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On 01/28/2012 01:46 PM, Jeff Davis wrote:
> 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.

-1 for that. A very quick look at initdb.c suggests to me that there are 
only two places where we'd need to put fsync(), right before we call 
fclose()  in write_file() and write_version_file(). If we're going to do 
anything that seems to be the least painful and most portable way to go.



In response to

pgsql-hackers by date

Next:From: Oleg BartunovDate: 2012-01-28 19:04:31
Subject: Re: TS: Limited cover density ranking
Previous:From: Jeff JanesDate: 2012-01-28 18:57:03
Subject: Re: initdb and fsync

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