Re: Vacuuming the operating system documentation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Vacuuming the operating system documentation
Дата
Msg-id 1940277.1591624260@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Vacuuming the operating system documentation  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-06-07 17:00, Tom Lane wrote:
>> Relevant to the current discussion: this creates a possible positive
>> reason for setting dynamic_shared_memory_type to "sysv", namely if it's
>> the best available way to get around RemoveIPC in a particular situation.
>> Should we document that?

> It sounds like both shared_memory_type and dynamic_shared_memory_type 
> ought to default to "sysv" on Linux.

Per the discussion in the older thread, that would only fix things if we
held at least one attach count constantly on every shared segment.  IIUC,
that's not guaranteed for DSAs.  So changing dynamic_shared_memory_type
would reduce the risk but not really fix anything.

For the primary shm segment, we don't (without EXEC_BACKEND) really
care if somebody unlinks the file prematurely, since backends inherit
the mapping via fork.  Hence, no need to change shared_memory_type.

            regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Bump default wal_level to logical
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: A wrong index choose issue because of inaccurate statistics