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 по дате отправления: