Re: fd.c: flush data problems on osx

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: fd.c: flush data problems on osx
Дата
Msg-id 21126.1460501444@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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>)
Список pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> On Mon, Mar 21, 2016 at 9:09 PM, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
>> On 21 Mar 2016, at 14:53, Andres Freund <andres@anarazel.de> wrote:
>>> I think we still need to fix the mmap() implementation to support the
>>> offset = 0, nbytes = 0 case (via fseek(SEEK_END).

>> It is already in this diff. I’ve added this few messages ago.

There are bigger issues in this code, actually, to wit assuming that
it should always be possible to mmap the target region.  That's patently
false on 32-bit machines, where you likely won't have a gigabyte of free
address space.

For this reason, I think that issuing a WARNING on mmap failure is a
damfool idea, and giving up on the flush attempt even more so.  We
should just silently fall through to the next implementation if we
cannot mmap the target region.

While I'm whinging: what happens when off_t is wider than size_t?  It's
entirely possible that the user has configured the relation segment size
to more than 4GB, so I do not think that's academic.  I think we also need
a test for length > SIZE_T_MAX and then fall through to another
implementation, rather than mapping and msync'ing some initial fragment of
the file, which is what will happen now.

> A similar change seems to be needed in initdb.c's pre_sync_fname.

Hmm, do we need to move this logic into src/common?
        regards, tom lane



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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Pglogical questions and problems
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Detrimental performance impact of ringbuffers on performance