From: | Jeff Janes <jeff(dot)janes(at)gmail(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>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: initdb and fsync |
Date: | 2012-01-28 18:57:03 |
Message-ID: | CAMkU=1wSfA65kz6zwDCjNV4AyeBp=Hnv74g_Ok4PFQdagqyOvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 28, 2012 at 10:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-01-28 18:59:51 | Re: initdb and fsync |
Previous Message | Kohei KaiGai | 2012-01-28 18:53:08 | Re: [v9.2] sepgsql's DROP Permission checks |