Tom Lane писал(а) 2025-03-26 22:38:
> Vladlen Popolitov <v.popolitov@postgrespro.ru> writes:
>> d) Above query will start parallel worker(s). When worker(s)
>> finish(es),
>> it/they send SIGUSR1 that is caught by debugger. When you dimiss
>> the signal message, you find that query continues to run, but really
>> it
>> waits (in latch.c or in waiteventset.c depending on commit version).
>
> I'm fairly skeptical of this. IME, when you see something like that,
> the actual problem is that the debugger has failed to pass the signal
> on to the program-under-test.
>
>> I tracked this behaviour down to commit
>> commit 7202d72787d3b93b692feae62ee963238580c877
>
> ... and that raises my skepticism to stratospheric levels, because
> that commit did exactly nothing that would have changed runtime
> behavior.
>
> regards, tom lane
Hi Tom,
I have not had the problems with the debugger and parallel workers
until this patch. I am on Mac with VScode as debug environment.
I asked my colleague to check it on Linux, and he reproduced it
immediately. As I remember, he usually uses gdb.
Usually a parallel worker informs the leader
through shared memory about it status. I am not sure, debugger can
affect this. I think, it creates additional pause, and leader does,
what it did not do without pause.
I also did not find something suspicious in the commit, but I checked
before and after tens commits (30-40) and binary search stopped on
this patch. Everyone after it reproduce this behaviour.
--
Best regards,
Vladlen Popolitov.
