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.
