Re: Posix Shared Mem patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Posix Shared Mem patch
Дата
Msg-id 15340.1340751525@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Posix Shared Mem patch  ("A.M." <agentm@themactionfaction.com>)
Ответы Re: Posix Shared Mem patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
"A.M." <agentm@themactionfaction.com> writes:
> This can be trivially reproduced if one runs an old (SysV shared memory-based) postgresql alongside a potentially
newerpostgresql with a smaller SysV segment. This can occur with applications that bundle postgresql as part of the
app.

I don't believe that that case is a counterexample to what's being
proposed (namely, grabbing a minimum-size shmem segment, perhaps 1K).
It would only fail if the old postmaster ate up *exactly* SHMMAX worth
of shmem, which is not real likely.  As a data point, on my Mac laptop
with SHMMAX set to 32MB, 9.2 will by default eat up 31624KB, leaving
more than a meg available.  Sure, that isn't enough to start another
old-style postmaster, but it would be plenty of room for one that only
wants 1K.

Even if you actively try to configure the shmem settings to exactly
fill shmmax (which I concede some installation scripts might do),
it's going to be hard to do because of the 8K granularity of the main
knob, shared_buffers.  Moreover, a installation script that did that
would soon learn not to, because of the fact that we don't worry too
much about changing small details of shared memory consumption in minor
releases.
        regards, tom lane


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Posix Shared Mem patch
Следующее
От: Nils Goroll
Дата:
Сообщение: experimental: replace s_lock spinlock code with pthread_mutex on linux