Re: fd.c: flush data problems on osx

From: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
To: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fd.c: flush data problems on osx
Date: 2016-03-21 11:46:09
Message-ID: 827E11CD-4D55-4E04-ABEC-971315C15F4E@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On 18 Mar 2016, at 14:45, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>>
>>> One possible solution for that is just fallback to pg_fdatasync in case when offset = nbytes = 0.
>>
>> Hm, that's a bit heavyweight. I'd rather do an lseek(SEEK_END) to get
>> the file size. Could you test that?
>>
>
> It looks like OSX mmap raises EINVAL when length isn’t aligned to pagesize while manual says it can be of arbitrary length, so i aligned it.
> Also there were call to mmap with PROT_READ | PROT_WRITE, but when called from pre_sync_fname file descriptor is just O_RDONLY, so i changed mmap mode to PROT_READ — seems that PROT_WRITE wasn’t needed anyway.
>
> And all of that reduces number of warnings in order of magnitude but there are still some and I don’t yet understand why are they happening.

I’ve spend some more time on this issue and found that remaining warnings were caused by mmap-ing directories — that raises EINVAL in OSX (probably not only OSX, but I didn’t tried).
So i’ve skipped mmap for dirs and now restore happens without warnings. Also I’ve fixed wrong error check that was in previous version of patch.

Attachment Content-Type Size
flushdata.v3.patch application/octet-stream 3.1 KB
unknown_filename text/plain 95 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-03-21 11:46:20 Re: Performance degradation in commit ac1d794
Previous Message Alexander Korotkov 2016-03-21 11:39:19 Re: improving GROUP BY estimation