| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> |
| Cc: | 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 15:38:57 |
| Message-ID: | 1615736.1743003537@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-03-26 15:41:13 | Re: vacuum_truncate configuration parameter and isset_offset |
| Previous Message | Nathan Bossart | 2025-03-26 15:28:26 | Re: vacuum_truncate configuration parameter and isset_offset |