Re: strange parallel query behavior after OOM crashes - Mailing list pgsql-hackers

From Neha Khatri
Subject Re: strange parallel query behavior after OOM crashes
Date
Msg-id CAFO0U+-E8yzchwVnvn5BeRDPgX2z9vZUxQ8dxx9c0XFGBC7N1Q@mail.gmail.com
Whole thread Raw
In response to Re: strange parallel query behavior after OOM crashes  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
List pgsql-hackers
Looking further in this context, number of active parallel workers is:
    parallel_register_count - parallel_terminate_count

Can active workers ever be greater than max_parallel_workers, I think no. Then why should there be greater than check in the following condition:

    if (parallel && (BackgroundWorkerData->parallel_register_count -
BackgroundWorkerData->parallel_terminate_count) >= max_parallel_workers)

I feel there should be an assert if
    (BackgroundWorkerData->parallel_register_count - BackgroundWorkerData->parallel_terminate_count) > max_parallel_workers)

And the check could be 
    if (parallel && (active_parallel_workers == max_parallel_workers))
        then do not register new parallel wokers and return.

There should be no tolerance for the case when active_parallel_workers > max_parallel_workers. After all that is the purpose of max_parallel_workers.

Is it like multiple backends trying to register parallel workers at the same time, for which the greater than check should be present?

Thoughts?

Regards,
Neha

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: Statement timeout behavior in extended queries
Next
From: 'Andres Freund'
Date:
Subject: Re: Statement timeout behavior in extended queries