Re: Providing anonymous mmap as an option of sharing memory

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Providing anonymous mmap as an option of sharing memory
Дата
Msg-id 15302.1069862961@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Providing anonymous mmap as an option of sharing memory  (Shridhar Daithankar <shridhar_daithankar@myrealbox.com>)
Ответы Re: Providing anonymous mmap as an option of sharing memory
Re: Providing anonymous mmap as an option of sharing memory
Список pgsql-hackers
Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes:
> I covered only first point in my post. IMO it is not such a unsolvable
> problem.  If a postmaster crashes hard but leaves a backend running,
> would it clean pid file etc? I don't think so. So if a postmaster can
> start on a 'pid-clean' state, then it is guaranteed to be no childs
> left around.

And that helps how?  The problem is to detect whether there are any
children left from the old postmaster, when what you have to work from
is the pid-file it left behind.

In any case, you're still handwaving away the very real portability
issues around mmap.  Linux is not the universe, and Linux+BSD isn't
either.

We might still have considered it, despite the negatives, if anyone had
been able to point to any actual *advantages* of mmap.  There are none.
Yes, the SysV shmem API is old and ugly and crufty, but it does what we
need it to do.
        regards, tom lane


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

Предыдущее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: A rough roadmap for internationalization fixes
Следующее
От: Greg Stark
Дата:
Сообщение: Re: detecting poor query plans