Re: ALTER DATABASE SET TABLESPACE vs crash safety
От | Alvaro Herrera |
---|---|
Тема | Re: ALTER DATABASE SET TABLESPACE vs crash safety |
Дата | |
Msg-id | 20081107163804.GD5507@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: ALTER DATABASE SET TABLESPACE vs crash safety (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Do we need to fsync the directory itself? My fsync(2) manpage says > > > Calling fsync() does not necessarily ensure that the entry in the directory > > containing the file has also reached disk. For that an explicit fsync() on a > > file descriptor for the directory is also needed. > > Hmm ... I see that in the Linux manpage, but not on Darwin, HPUX, or in > the Single Unix Spec. I'm inclined to argue that we've always expected > the filesystem to take care of its own metadata, and we've never seen > any indication that that's unsafe. We don't try to "fsync the > directory" after a normal table create for instance. I dimly recall the Postfix guys got burned by this some time ago (mails got lost after a crash because they didn't fsync the directory on which they had just created the files before acknowledging the email delivery to the remote server). I guess this is the reason we require a filesystem that journals metadata. http://osdir.com/ml/file-systems.reiserfs.general/2003-09/msg00120.html -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: