Re: initdb and fsync

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, 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-06-22 14:04:23
Message-ID: CA+TgmoayOyfhwfZbcXZTpnfqFxjNzrQdwAeFEvhHV7caVr_p7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 4, 2012 at 8:18 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Sat, Feb 04, 2012 at 03:41:27PM -0800, Jeff Davis wrote:
>> On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
>> > 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 worked up a patch, and it looks like it does about 6 file fsync's and
>> a 7th for the PGDATA directory. That degrades the time from about 1.1s
>> to 1.4s on my workstation.
>
>> So, is it worth it? Should we make it an option that can be specified?
>
> If we add fsync calls to the initdb process, they should cover the entire data
> directory tree.  This patch syncs files that initdb.c writes, but we ought to
> also sync files that bootstrap-mode backends had written.  An optimization
> like the pg_flush_data() call in copy_file() may reduce the speed penalty.
>
> initdb should do these syncs by default and offer an option to disable them.

This may be a stupid question, by why is it initdb's job to fsync the
files the server creates, rather than the server's job? Normally we
rely on the server to make its own writes persistent.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-06-22 14:09:59 Re: [PATCH 01/16] Overhaul walsender wakeup handling
Previous Message Robert Haas 2012-06-22 13:55:13 Re: proposal and patch : support INSERT INTO...RETURNING with partitioned table using rule