Re: fd.c: flush data problems on osx - Mailing list pgsql-hackers

From Stas Kelvich
Subject Re: fd.c: flush data problems on osx
Date
Msg-id EC709BD9-07D1-401E-9459-A9ABAB358FA4@postgrespro.ru
Whole thread Raw
In response to Re: fd.c: flush data problems on osx  (Andres Freund <andres@anarazel.de>)
Responses Re: fd.c: flush data problems on osx
List pgsql-hackers
> On 17 Mar 2016, at 20:23, Andres Freund <andres@anarazel.de> wrote:
>
>>
>> Also there are no default ifdef inside this function, is there any
>> check that will guarantee that pg_flush_data will not end up with
>> empty body on some platform?
>
> There doesn't need to be - it's purely "advisory", i.e. just an
> optimization.


Ah, okay, then I misinterpret purpose of that function and it shouldn’t be forced to sync.

>
>> 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
whyare they happening. 

>
> Greetings,
>
> Andres Freund
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

---
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company





Attachment

pgsql-hackers by date:

Previous
From: Yury Zhuravlev
Date:
Subject: Re: GinPageIs* don't actually return a boolean
Next
From: David Steele
Date:
Subject: Re: jsonb array-style subscription