|From:||Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: fd.c: flush data problems on osx|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 17 Mar 2016, at 20:23, Andres Freund <andres(at)anarazel(dot)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
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 why are they happening.
> Andres Freund
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
|Next Message||David Steele||2016-03-18 12:03:12||Re: jsonb array-style subscription|
|Previous Message||Yury Zhuravlev||2016-03-18 11:36:23||Re: GinPageIs* don't actually return a boolean|