From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Bernd Helmle <mailings(at)oopsware(dot)de> |
Subject: | Re: ALTER DATABASE SET TABLESPACE vs crash safety |
Date: | 2008-11-07 16:38:04 |
Message-ID: | 20081107163804.GD5507@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2008-11-07 16:58:20 | gram.y=>preproc.y II |
Previous Message | Tom Lane | 2008-11-07 16:23:37 | Re: ALTER DATABASE SET TABLESPACE vs crash safety |