On Sat, Jan 28, 2012 at 10:18 AM, Tom Lane <t...@sss.pgh.pa.us> 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. > > regards, tom lane
Does sync(2) behave like sync(8) and flush the entire system cache, or does it just flush the files opened by the process which called it? The man page didn't enlighten me on that. sometimes sync(8) never returns. It doesn't just flush what was dirty at the time it was called, it actually keeps running until there are simultaneously no dirty pages anywhere in the system. On busy systems, this condition might never be reached. And it can't be interrupted, not even with kill -9. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
