Re: Let's remove DSM_INPL_NONE.
От | Tom Lane |
---|---|
Тема | Re: Let's remove DSM_INPL_NONE. |
Дата | |
Msg-id | 32164.1519761235@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Let's remove DSM_INPL_NONE. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Let's remove DSM_INPL_NONE.
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2018-02-27 14:41:47 -0500, Tom Lane wrote: >> 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. Ah. That's a fair point, but I do not think dynamic_shared_memory_type=none is a good substitute for having a way to provoke allocation failures. That doesn't let you test recovery from situations where your first allocation works and second one fails, for example; and cleanup from that sort of case is likely to be more complicated than the trivial case. regards, tom lane
В списке pgsql-hackers по дате отправления: