Re: [HACKERS] strange parallel query behavior after OOM crashes
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] strange parallel query behavior after OOM crashes |
Дата | |
Msg-id | CA+TgmoZyCNU6_TnCPNsSo+Z3oRxUJpCsHzfmvasFkswsXroqvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] strange parallel query behavior after OOM crashes (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] strange parallel query behavior after OOM crashes
|
Список | pgsql-hackers |
On Mon, Apr 10, 2017 at 7:17 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > At first I was like 'WTF? Why do we need a new GUC just becase of an > assert?' but you're actually not adding a new GUC parameter, you're adding a > constant which is then used as a max value for max for the two existing > parallel GUCs. > > I think this is fine. I think it is pretty odd-looking. As written, it computes an unsigned -- and therefore necessarily non-negative -- value into a signed -- and thus possibly neative -- value only to pass it back to abs() to make sure it's not negative: + Assert(!parallel || abs((int)(BackgroundWorkerData->parallel_register_count - + BackgroundWorkerData->parallel_terminate_count)) <= + MAX_PARALLEL_WORKER_LIMIT); I think we can just say Assert(!parallel || BackgroundWorkerData->parallel_register_count - BackgroundWorkerData->parallel_terminate_count <= MAX_PARALLEL_WORKER_LIMIT); -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: