On Monday 15 February 2010 12:34:44 marcin mank wrote: > On Mon, Feb 15, 2010 at 11:02 AM, Andres Freund <and...@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 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
> 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 That does seem to be a different issue. Currently there are no fsyncs on directories at all, so likely your setup is hosed anyway ;-) > But I would not be that sure that eg. NFS or something like that won`t > complain. It does not. > Ignoring the return code seems the right choice. And the error hiding one as well. With delayed allocation you theoretically could error out on fsync with -ENOSPC ... Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
