| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: sblock state on FreeBSD 6.1 |
| Date: | 2006-05-11 19:58:33 |
| Message-ID: | 20060511195833.GG10873@surnet.cl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jim C. Nasby wrote:
> Yeah, my suspicion is that those processes had moved past waiting on the
> socket lock by the time gdb got to them. Any idea of how you could tell
> what state (as reported by top) the process was in when gdb stopped it?
I think you could send SIGSTOP to all backends at once, then grab the
backtraces with GDB, then restart them. That way, all backends will
appear to be in the same frozen state, instead of having some in an
"earlier" state than others.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-05-11 20:00:28 | Re: [HACKERS] Big IN() clauses etc : feature proposal |
| Previous Message | Jim C. Nasby | 2006-05-11 19:57:10 | Re: [HACKERS] Big IN() clauses etc : feature proposal |