From: | Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nikita Malakhov <hukutoc(at)gmail(dot)com> |
Subject: | Re: Current master hangs under the debugger after Parallel Seq Scan (Linux, MacOS) |
Date: | 2025-03-27 06:23:27 |
Message-ID: | 95c1061dd45b0183e8b79052f9963ba0@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | wenhui qiu | 2025-03-27 06:29:17 | Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available |
Previous Message | David Rowley | 2025-03-27 05:43:29 | Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET |