Andres Freund писал(а) 2025-03-27 01:22:
Hi,
Isn't that to be expected? If I understand correctly, the way your gdb
is
configured is that it intercepts SIGUSR1 signals *without* passing it
on to
the application (i.e. postgres). We rely on the signal to be
delivered. Which
it isn't. Thus a hang.
At least my gdb doesn't intercept SIGUSR1 by default. It's a newer gdb
though,
so that could have been different in the past (although I don't
remember a
different behaviour).
(gdb) handle SIGUSR1
Signal Stop Print Pass to program Description
SIGUSR1 No No Yes User defined signal 1
If I change the configuration to not pass it, but print it, I can
reproduce a
hang:
handle SIGUSR1 print nopass
What does your gdb show for "handle SIGUSR1"? If it isn't what I
reported, is
it possible that you set that in your .gdbinit or such?
2. Original commit with reproducible behaviour.
I tracked this behaviour down to commit
> commit 7202d72787d3b93b692feae62ee963238580c877
> Date: Fri Feb 21 08:03:33 2025 +0100
> backend launchers void * arguments for binary data
> Change backend launcher functions to take void * for binary data
> instead of char *. This removes the need for numerous casts.
> Discussion:
https://www.postgresql.org/message-id/flat/fd1fcedb-3492-4fc8-9e3e-74b97f2db6c7%40eisentraut.org
I also find it very hard to believe that this commit introduced this
problem -
it doesn't sound like a postgres issue to me. I can reproduce it in PG
16,
after doing "handle SIGUSR1 print nopass".
Greetings,
Andres Freund
Dear colleagues,
I changed the debugging extension in VScode (from C_Cpp to CodeLLDB) and
this hang disappeared. Thank you for pointing, that it more relates to
a debugger than Postgres.
Both extensions process signals internally and do not expose the
handlers
in settings.
Thank you for your support and time.
--
Best regards,
Vladlen Popolitov.
