Re: Fails to work on live images due to fsync() on pg_commit_ts before doing any write there

Alvaro, Raphael,

* Alvaro Herrera (alvherre(at)alvh(dot)no-ip(dot)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