Let's remove DSM_INPL_NONE.

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Let's remove DSM_INPL_NONE.
Date: 2018-02-15 10:58:57
Message-ID: 20180215.195857.109347328.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


As in the other threads[1][2], we have had several good reasons
to remove DSM_IMPL_NONE in PG11. The attached patch doesn that.

[1] https://www.postgresql.org/message-id/CA+Tgmoa0e23YC3SCwB85Yf5oUTRyirV=Sq_rXYxaXABLdPpjoA@mail.gmail.com

[2] https://www.postgresql.org/message-id/20180214.103858.02713585.horiguchi.kyotaro@lab.ntt.co.jp

It is amost a just-to-delete work but I see two issues raised so

1. That change can raise regression test failure on some
buildfarm machines[3].

The reason is that initdb creates a database with
max_connection=10 from DSM failure caused by semaphore exhaustion
, even though regression test requires at least 20
connections. At that time it was "fixed" by setting
dynamic_shared_memory_type=none while detecting the number of
usable max_connections and shared buffers[4]. Regardless of
whether the probing was succeeded or not, initdb finally creats a
database on that any DSM implementation is activated, since
initdb doesn't choose "none". Finally the test items for parallel
query actually suceeded.

For the reason above, I believe just increasing the minimum
fallback value of max_connections to 20 will work[5]. Anyway it
is a problem to be fixed that initdb creates an inexecutable
database if it uses the fallback values of max_connections=10.

[3] https://www.postgresql.org/message-id/CA+TgmoYHiiGrcvSSJhmbSEBMoF2zX_9_9rWd75Cwvu99YrDxew@mail.gmail.com

[4] Commit: d41ab71712a4457ed39d5471b23949872ac91def

[5] https://www.postgresql.org/message-id/20180209.170823.42008365.horiguchi.kyotaro@lab.ntt.co.jp

2. Server may chooose unusable DSM implementation while initdb probing.


> Feel free to. Be just careful that the connection attempts in
> test_config_settings() should try to use the DSM implementation defined
> by choose_dsm_implementation().

Thank you for the advice. The probing fails with the default
setting if posix shared memory somehow fails on a platform like
Linux that is usually expected to have it. It's enough to choose
the implementation before probing. Some messages from initdb are
transposed as the result.

| creating directory /home/horiguti/data/data_ndsm ... ok
| creating subdirectories ... ok
| + selecting dynamic shared memory implementation ... posix
| selecting default max_connections ... 100
| selecting default shared_buffers ... 128MB
| - selecting dynamic shared memory implementation ... posix

Even though probing can end with failure in the case of [3], it
will not be a problem with the patch [4].


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
0001-Remove-dynamic_shared_memroy_type-none.patch text/x-patch 8.5 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2018-02-15 11:04:47 Removing useless #include's.
Previous Message Ashutosh Bapat 2018-02-15 10:48:46 Re: [HACKERS] why not parallel seq scan for slow functions