From: | marcin mank <marcin(dot)mank(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Greg Stark <stark(at)mit(dot)edu> |
Subject: | Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |
Date: | 2010-02-15 11:34:44 |
Message-ID: | b1b9fac61002150334k25a4977aj1f73e9dbcc2279a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Feb 15, 2010 at 11:02 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi Marcin,
>
> Sounds rather unlikely to me. Its likely handled at an upper layer (vfs in linux' case) and only overloaded when an optimized implementation is available.
> Which os do you see implementing that only on a part of the filesystems?
>
I have a Windows XP dev machine, which runs virtualbox, which runs
ubuntu, which mounts a windows directory through vboxfs
fsync does error out on directories inside that mount.
btw: 8.4.2 initdb won`t work there too, So this is not a regression.
The error is:
DEBUG: creating and filling new WAL file
LOG: could not link file "pg_xlog/xlogtemp.2367" to
"pg_xlog/000000010000000000000000" (initialization of log file 0,
segment 0): Operation not permitted
FATAL: could not open file "pg_xlog/000000010000000000000000" (log
file 0, segment 0): No such file or directory
But I would not be that sure that eg. NFS or something like that won`t complain.
Ignoring the return code seems the right choice.
Greetings
Marcin Mańk
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-02-15 11:40:51 | pgsql: Temporarily disable fsyncing the database directory in CREATE |
Previous Message | Greg Stark | 2010-02-15 11:19:24 | Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2010-02-15 11:36:10 | Re: buildfarm breakage |
Previous Message | Joachim Wieland | 2010-02-15 11:33:45 | Re: LISTEN/NOTIFY and notification timing guarantees |