Re: fd.c: flush data problems on osx

Поиск
Список
Период
Сортировка
От Stas Kelvich
Тема Re: fd.c: flush data problems on osx
Дата
Msg-id 827E11CD-4D55-4E04-ABEC-971315C15F4E@postgrespro.ru
обсуждение исходный текст
Ответ на Re: fd.c: flush data problems on osx  (Stas Kelvich <s.kelvich@postgrespro.ru>)
Ответы Re: fd.c: flush data problems on osx  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
> 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 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. 

I’ve spend some more time on this issue and found that remaining warnings were caused by mmap-ing directories — that
raisesEINVAL 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
previousversion of patch. 




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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: improving GROUP BY estimation
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation in commit ac1d794