Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there - Mailing list pgsql-bugs

From Stephen Frost
Subject Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there
Date
Msg-id 20171107141827.GW4628@tamriel.snowman.net
Whole thread Raw
In response to Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-bugs
Alvaro, Raphael,

* Alvaro Herrera (alvherre@alvh.no-ip.org) wrote:
> Raphael Hertzog wrote:
>
> > PostgreSQL 10 no longer works on a (Kali) live system where the
> > root filesystem is an overlayfs with an underlying squashfs
> > filesystem (where postgresql and its initial file structure
> > is present) and a writable tmpfs overlay.
>
> Please create a machine that works this way and get it added to the
> buildfarm, so that this sort of thing doesn't surprise us in the future
> months after the fact.

While I agree with this, I'm not entirely convinced that this isn't an
issue with the implementation of the underlying filesystem after all.  I
haven't had a chance to go read those other bug reports, but my fsync()
manpage pretty clearly seems to say that fsync should only be returning
EINVAL if it's called on a special file (FIFO, pipe, et al).  There's
certainly no indication that it's ok for the same file to sometimes
support fsync() and other times *not* support fsync().  That's pretty
bizarre.

Why wouldn't it make sense for the filesystem to realize it's a no-op if
there's been no changes?

Thanks!

Stephen

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there
Next
From: Raphael Hertzog
Date:
Subject: Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there