Re: fd.c: flush data problems on osx

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: fd.c: flush data problems on osx
Дата
Msg-id
20160317172328.uohb5bkwfszrlkqb@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
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>
Re: fd.c: flush data problems on osx Stas Kelvich <s.kelvich@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>
Re: fd.c: flush data problems on osx Stas Kelvich <s.kelvich@postgrespro.ru>
Re: fd.c: flush data problems on osx Noah Misch <noah@leadboat.com>
Re: fd.c: flush data problems on osx Michael Paquier <michael.paquier@gmail.com>
Re: fd.c: flush data problems on osx Tom Lane <tgl@sss.pgh.pa.us>
Re: fd.c: flush data problems on osx Tom Lane <tgl@sss.pgh.pa.us>
Re: fd.c: flush data problems on osx Andres Freund <andres@anarazel.de>
Re: fd.c: flush data problems on osx Tom Lane <tgl@sss.pgh.pa.us>
Re: fd.c: flush data problems on osx Andres Freund <andres@anarazel.de>
Re: fd.c: flush data problems on osx Tom Lane <tgl@sss.pgh.pa.us>
Re: fd.c: flush data problems on osx Andres Freund <andres@anarazel.de>
Re: fd.c: flush data problems on osx Tom Lane <tgl@sss.pgh.pa.us>
Hi,

On 2016-03-17 20:09:53 +0300, Stas Kelvich wrote:
> Current implementation of pg_flush_data when called with zero offset and zero nbytes is assumed to flush all file. In osx it uses mmap with these arguments, but according to man: 
> 
> "[EINVAL]           The len argument was negative or zero. Historically, the system call would not return an
>                         error if the argument was zero.  See other potential additional restrictions in the COMPAT-
>                         IBILITY section below."
> 
> so it is generate a lot of warnings:
> 
> "WARNING:  could not mmap while flushing dirty data: Invalid argument"

Hm, yea, that's buggy.


> 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?


> 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.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления
От: David Steele
Дата:
От: Alvaro Herrera
Дата:
FAQ