| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Printing backtrace of postgres processes |
| Date: | 2020-12-01 03:31:03 |
| Message-ID: | 20201201033103.cebj56i3s57zytuy@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2020-11-30 13:35:46 +0800, Craig Ringer wrote:
> I find that when I most often want a backtrace of a running, live
> backend, it's because the backend is doing something that isn't
> passing a CHECK_FOR_INTERRUPTS() so it's not responding to signals. So
> it wouldn't help if a backend is waiting on an LWLock, busy in a
> blocking call to some loaded library, a blocking syscall, etc. But
> there are enough other times I want live backtraces, and I'm not the
> only one whose needs matter.
Random thought: Wonder if it could be worth adding a conditionally
compiled mode where we track what the longest time between two
CHECK_FOR_INTERRUPTS() calls is (with some extra logic for client
IO).
Obviously the regression tests don't tend to hit the worst cases of
CFR() less code, but even if they did, we currently wouldn't know from
running the regression tests.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2020-12-01 03:33:15 | Re: Printing backtrace of postgres processes |
| Previous Message | Andres Freund | 2020-12-01 03:26:49 | Re: Printing backtrace of postgres processes |