On 01/28/2012 01:46 PM, Jeff Davis wrote:
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
Andrew Dunstan<and...@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.
-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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
