Re: strange parallel query behavior after OOM crashes

On 04/05/2017 04:26 PM, Kuntal Ghosh wrote:
> On Wed, Apr 5, 2017 at 7:45 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
>> <kuntalghosh(dot)2007(at)gmail(dot)com> wrote:
>>>> Did you intend to attach that patch to this email?
>>>>
>>> Actually, I'm confused how we should ensure (register_count >
>>> terminate_count) invariant. I think there can be a system crash what
>>> Tomas has suggested up in the thread.
>>>
>>> Assert(parallel_register_count - parallel_terminate_count <=
>>> max_parallel_workers);
>>> Backend 1 > SET max_parallel_worker = 8;
>>> Backend 1 > Execute a long running parallel query q1 with number of
>>> parallel worker spawned is say, 4.
>>
>> At this point, parallel_register_count should be equal to
>> parallel_terminate_count. 4 workers were started, and 4 have
>> terminated.
>>
> Actually, I'm referring to the case when q1 is still running. In that
> case, parallel_register_count = 4 and parallel_terminate_count = 0.
>
>>> Backend 2> SET max_parallel_worker = 3;
> Now, parallel_register_count - parallel_terminate_count = 4 >
> max_parallel_worker.
>
>>> Backend 2 > Try to execute any parallel query q2 with number of
>>> parallel worker spawned > 0.
>>
> Hence, the assert will fail here.
>

Actually, you probably don't even need two sessions to trigger the
assert. All you need is to tweak the max_parallel_workers and then
reload the config while the parallel query is running. Then
ForgetBackgroundWorker() will see the new value.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services