Re: Let's remove DSM_INPL_NONE.
От | Tom Lane |
---|---|
Тема | Re: Let's remove DSM_INPL_NONE. |
Дата | |
Msg-id | 31962.1519792222@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Let's remove DSM_INPL_NONE. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Let's remove DSM_INPL_NONE.
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Feb 27, 2018 at 2:50 PM, Andres Freund <andres@anarazel.de> wrote: >> 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. > Well, it's not very hard to just hack the code to make dsm_create() > always fail, or fail X% of the time, if you're so inclined. I agree > that -c dynamic_shared_memory_type=none is a little more convenient > than sticking something like that into the code, but I don't think > it's sufficiently more convenient to justify keeping an option we > don't otherwise want. I'd be in favor of having some normally-ifdef'd-out facility for causing failures of this kind. (As I mentioned upthread, I do not think "always fail" is sufficient.) That's very different from having a user-visible option, though. We don't expose a GUC that enables CLOBBER_FREED_MEMORY, to take a relevant example. regards, tom lane
В списке pgsql-hackers по дате отправления: