| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
| Cc: | Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, hukutoc(at)gmail(dot)ru |
| Subject: | Re: Current master hangs under the debugger after Parallel Seq Scan (Linux, MacOS) |
| Date: | 2025-03-26 17:40:19 |
| Message-ID: | CA+TgmoaUrK8U+Osa72+qAUhZUq7PD8pbF8+6JrZgoxVQ2ozWVg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 26, 2025 at 12:32 PM Nikita Malakhov <hukutoc(at)gmail(dot)com> wrote:
> Vladlen, I've checked your example and also got this behavior
> on the current master under Gdb (Ubuntu 22.04 LTS).
>
> On the query above server waits in this state (as shown by gdb):
> Program received signal SIGUSR1, User defined signal 1.
> 0x0000562beb21c6ed in ExecInterpExpr (state=0x562bec781858, econtext=<optimized out>, isnull=<optimized out>) at execExprInterp.c:625
> 625 return state->resvalue;
>
> Although, the process continues to work normally after gdb is detached from it.
Do either of you have any theory as to how removing a cast could cause
this behavior?
The only idea that occurs to me is a bug in gdb.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2025-03-26 17:54:23 | Re: vacuum_truncate configuration parameter and isset_offset |
| Previous Message | Nikolay Shaplov | 2025-03-26 17:29:17 | Re: vacuum_truncate configuration parameter and isset_offset |