On Mon, Jan 2, 2012 at 04:00:19PM -0500, Tom Lane wrote: > Alvaro Herrera <alvhe...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
