> On 17 Mar 2016, at 20:23, Andres Freund <and...@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 why are 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
flushdata.v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
