Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there
От | Stephen Frost |
---|---|
Тема | Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there |
Дата | |
Msg-id | 20171107141827.GW4628@tamriel.snowman.net обсуждение исходный текст |
Ответ на | 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>) |
Список | 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 по дате отправления: