On Thu, 2025-09-04 at 10:22 +1200, Thomas Munro wrote:
> This seems like a non-problem. Robustness against SIGSTOP of random
> backends is not a project goal or reasonable goal, is it?
I think you misinterpreted -- I wasn't suggesting that sending SIGSTOP
is a use case. I just meant that it showed a strong dependence between
the processes, and that it might be more robust to have some kind of
fallback.
> * I have a patch basically ready to commit for v19 (CF #5913) that
> would automatically add more workers if you did that. But even then
> you could be unlucky and SIGSTOP a worker while it holds the
> submission queue lock.
Making it adaptable sounds like a nice improvement, especially since we
don't have good guidance in the docs about how to tune it.
> * I also had experimental versions that use a lock free queue, but it
> didn't seem necessary given how hard it is to measure meaningful lock
> contention so far;
Andres suggested that the case I brought up at the top of the thread is
due to lock contention, so a lock free queue also sounds like a
potential improvement. If the code is working and can be applied to
REL_18_STABLE, then I can try it.
Regards,
Jeff Davis
