Re: Vacuuming the operating system documentation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Vacuuming the operating system documentation
Дата
Msg-id 1737266.1591542027@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Vacuuming the operating system documentation  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Vacuuming the operating system documentation  (Thomas Munro <thomas.munro@gmail.com>)
Re: Vacuuming the operating system documentation  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> One more thing I spotted, post commit: the example symptom of
> systemd's RemoveIPC feature trashing your cluster is an error from
> semctl(), but that can't happen anymore on a standard build.

Good point.

> Not sure
> what to put in its place... I guess the remaining symptoms would be
> (1) the little "interlock" shmem segment is unregistered, which is
> probably symptom-free (until you start a second postmaster in the same
> pgdata), and (2) POSIX shm objects getting unlinked underneath a
> parallel query.

(1) would be very scary, because the "symptom" would be "second postmaster
successfully starts and trashes your database".  But our previous
discussion found that that won't happen, because systemd notices the
segment's positive nattch count.  Unfortunately it seems there's nothing
equivalent for POSIX shmem, so (2) is possible.  See

https://www.postgresql.org/message-id/5915.1481218827%40sss.pgh.pa.us

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?

            regards, tom lane



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

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Debian Sid broke Perl