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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER DATABASE SET TABLESPACE vs crash safety
Следующее
От: Michael Meskes
Дата:
Сообщение: gram.y=>preproc.y II