| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Let's remove DSM_INPL_NONE. |
| Date: | 2018-02-28 00:57:32 |
| Message-ID: | 20180228005732.GA1476@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 27, 2018 at 02:00:36PM -0500, Robert Haas wrote:
> 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.
Yes, that's what the thing does. It moves the routine to find the DSM
implementation before computing max_connections.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-02-28 01:08:59 | Re: Let's remove DSM_INPL_NONE. |
| Previous Message | Alvaro Herrera | 2018-02-28 00:46:02 | ON CONFLICT DO UPDATE for partitioned tables |