Re: Let's remove DSM_INPL_NONE.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Let's remove DSM_INPL_NONE.
Дата
Msg-id CA+TgmobzaHavxZGParmJy9f-Jgivxe+GQ0j1jcpm3rn1T6wR-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Let's remove DSM_INPL_NONE.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Let's remove DSM_INPL_NONE.  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Thu, Feb 15, 2018 at 5:58 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> It is amost a just-to-delete work but I see two issues raised so
> far.

I think the two issues you are pointing out are the same issue --
namely, if initdb probes for a max_connections setting with an invalid
DSM implementation configured, it will fail the test for every value
of max_connections and thus select the lowest possible value.  The
solution to this is presumably just to make sure we choose the DSM
implementation before we do the max_connections probing so that we can
pass through the correct value there, which I think is what your patch
does.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: atomics.h may not be included from frontend code
Следующее
От: Andres Freund
Дата:
Сообщение: Re: ALTER TABLE ADD COLUMN fast default