On Wed, Nov 8, 2017 at 12:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>> My thought about this is just to ignore EINVAL when fsync'ing a directory,
>>> as we already do with EBADF.
>
>> Yeah, I suppose we could, just not sure that an EINVAL should really be
>> getting returned here, imv.
>
> Yeah, it does sound more like a filesystem bug than anything else.
> (I completely reject the notion that it's an application error to
> fsync a directory when you haven't modified it.)
>
> In view of the fact that we just wrapped 10.1, it'd be 3 months before
> any change from our side would reach the wild. I think a key question
> here is whether the Kali developers are likely to fix it from their side
> in less time than that.
FWIW, after sleeping on the matter and thinking about it. I agree that
we should do nothing in Postgres code. Even for a code path calling
fsync_fname_ext() and expecting a directory, I think that we really
should report EINVAL if the operation is performed on an incorrect
entry. That will be useful for any future code, but that's actually
useful for any application developer. Note that when we discussed
about 1b02be2, we thought as well about not doing the fsync when there
have been no modifications, particularly for pg_twophase, however the
flush is necessary particularly to keep durability of transactions
prepared and committed during the same checkpoint cycle. And this
keeps the code dead simple.
I tend to think that 1b02be2 ought to be back-patched as well, as not
protecting durability guarantees is no good.
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
