On Mon, Jan 2, 2012 at 04:00:19PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Excerpts from Tom Lane's message of lun ene 02 17:28:33 -0300 2012:
> >> it seems like EINVAL is a considerably more reasonable thing to return
> >> than EBADF, if the filesystem is trying to tell you that it won't fsync
> >> a directory. So I'm a bit surprised this question hasn't come up for
> >> other filesystems.
>
> > Probably because other filesystems do allow you to fsync directories.
> > In fact for some cases they _require_ it ... remember the fiasco when
> > MTA writers were told that they needed to fsync their queue dirs in
> > order for all queued email to persist?
>
> Yeah, the long and the short of it is that if the filesystem won't
> accept an fsync on a directory, we have to assume that it doesn't need
> it and will manage metadata persistence safely without prodding.
>
> The only real question here is whether an EINVAL could mean something
> besides "fsync on directory is not accepted". If there are any
> scenarios where it represents a transient/fixable error, then we'd
> want to report it. It's far from clear to me that there are any
> though. What it could mean in general is not at issue, because we
> know the target is a directory that we just created moments before.
I assume this never got resolved. Should it be changed to ignore
EINVAL?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
