Thread: Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there
Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there
From
Michael Paquier
Date:
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