Re: fd.c: flush data problems on osx

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Mon, Mar 21, 2016 at 9:09 PM, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>> On 21 Mar 2016, at 14:53, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> I think we still need to fix the mmap() implementation to support the
>>> offset = 0, nbytes = 0 case (via fseek(SEEK_END).

>> It is already in this diff. Ive added this few messages ago.

There are bigger issues in this code, actually, to wit assuming that
it should always be possible to mmap the target region. That's patently
false on 32-bit machines, where you likely won't have a gigabyte of free
address space.

For this reason, I think that issuing a WARNING on mmap failure is a
damfool idea, and giving up on the flush attempt even more so. We
should just silently fall through to the next implementation if we
cannot mmap the target region.

While I'm whinging: what happens when off_t is wider than size_t? It's
entirely possible that the user has configured the relation segment size
to more than 4GB, so I do not think that's academic. I think we also need
a test for length > SIZE_T_MAX and then fall through to another
implementation, rather than mapping and msync'ing some initial fragment of
the file, which is what will happen now.

> A similar change seems to be needed in initdb.c's pre_sync_fname.

Hmm, do we need to move this logic into src/common?

regards, tom lane