From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: initdb and fsync |
Date: | 2012-03-13 03:49:40 |
Message-ID: | 1331610580.6425.98.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2012-02-05 at 17:56 -0500, Noah Misch wrote:
> I meant primarily to illustrate the need to be comprehensive, not comment on
> which executable should fsync a particular file. Bootstrap-mode backends do
> not sync anything during an initdb run on my system. With your patch, we'll
> fsync a small handful of files and leave nearly everything else vulnerable.
Thank you for pointing that out. With that in mind, I have a new version
of the patch which just recursively fsync's the whole directory
(attached).
I also introduced a new option --nosync (-N) to disable this behavior.
The bad news is that it introduces a lot more time to initdb -- it goes
from about 1s to about 10s on my machine. I tried fsync'ing the whole
directory twice just to make sure that the second was a no-op, and
indeed it didn't make much difference (still about 10s).
That's pretty inefficient considering that
initdb -D data --nosync && sync
only takes a couple seconds. Clearly batching the operation is a big
help. Maybe there's some more efficient way to fsync a lot of
files/directories? Or maybe I can mitigate it by avoiding files that
don't really need to be fsync'd?
Regards,
Jeff Davis
Attachment | Content-Type | Size |
---|---|---|
initdb-fsync-20120312.patch.gz | application/x-gzip | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-03-13 04:12:27 | Re: pg_upgrade and statistics |
Previous Message | Fujii Masao | 2012-03-13 03:36:45 | Re: xlog location arithmetic |