Re: initdb and fsync
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Noah Misch <noah@leadboat.com>, pgsql-hackers@postgresql.org
Date: 2012-01-28T18:46:06Z
Lists: pgsql-hackers
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.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