Tom Lane писал(а) 2025-03-26 22:38:
Vladlen Popolitov <v.popoli...@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.
