Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
От | marcin mank |
---|---|
Тема | Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |
Дата | |
Msg-id | b1b9fac61002150334k25a4977aj1f73e9dbcc2279a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by
deferring the fsyncs until after
Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |
Список | pgsql-hackers |
On Mon, Feb 15, 2010 at 11:02 AM, Andres Freund <andres@anarazel.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 optimizedimplementation 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
В списке pgsql-hackers по дате отправления: