Re: fd.c: flush data problems on osx
От | Andres Freund |
---|---|
Тема | Re: fd.c: flush data problems on osx |
Дата | |
Msg-id | 20160321115332.bfemw6tyy26jxhfb@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: fd.c: flush data problems on osx (Stas Kelvich <s.kelvich@postgrespro.ru>) |
Ответы |
Re: fd.c: flush data problems on osx
|
Список | pgsql-hackers |
On 2016-03-21 14:46:09 +0300, Stas Kelvich wrote: > > > On 18 Mar 2016, at 14:45, Stas Kelvich <s.kelvich@postgrespro.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 justO_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 understandwhy 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. Hm. I think we should rather just skip calling pg_flush_data in the directory case, that very likely isn't beneficial on any OS. I think we still need to fix the mmap() implementation to support the offset = 0, nbytes = 0 case (via fseek(SEEK_END). Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: