Re: Let's remove DSM_INPL_NONE.
От | Andres Freund |
---|---|
Тема | Re: Let's remove DSM_INPL_NONE. |
Дата | |
Msg-id | 20180227195013.o6r3ahyzqlsyydrp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Let's remove DSM_INPL_NONE. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Let's remove DSM_INPL_NONE.
Re: Let's remove DSM_INPL_NONE. |
Список | pgsql-hackers |
On 2018-02-27 14:41:47 -0500, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Thu, Feb 15, 2018 at 1:00 PM, Andres Freund <andres@anarazel.de> wrote: > >> Hm, I'm not quite convinced by this. Seems to make testing a bunch of > >> codepaths harder. I think it's fine to say that pg doesn't work > >> correctly with them disabled though. > > > I'm not sure I understand this. Do you mean we should just add a > > disclaimer to the documentation? > > What I didn't understand about it was what kind of testing this'd make > harder. If we desupport dynamic_shared_memory_type=none, there aren't > any code paths that need to cope with the case, and we should just > remove any code that thereby becomes unreachable. What I'm concerned about isn't so much testing paths specific to dynamic_shared_memory_type=none, but paths where we currently need fallbacks for the case we couldn't actually allocate dynamic shared memory. Which I think we at least somewhat gracefully need to deal with. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: