On Thu, May 11, 2006 at 02:39:14PM -0500, Jim C. Nasby wrote:
> On Thu, May 11, 2006 at 07:39:23PM +0200, Martijn van Oosterhout wrote:
> > This is an idle backend waiting for the user.
>
> So why would that be waiting to lock the socket? My understanding is
> that nothing else should be contending for that socket, no?
I'm not sure about locks, but it will be blocking on the socket...
> > > #0 0x000000080137638c in sendto () from /lib/libc.so.6
> > > #1 0x0000000000535e67 in pgstat_report_tabstat () at pgstat.c:846
> >
> > This definitly the statistics collector, which is something that was
> > speculated upthread. Do you get a lot of these?
>
> I included everything that was captured, but of course that's only a
> small sampling. If it's helpful we could probably setup something that
> would automatically grab stack traces for a larger number of backends
> and then see how many were in that state.
If you know the pids you should be able to within gdb just do
attach/bt/detech. gdb has some redimentary scripting capabilites so you
might be able to do this fairly quickly.
> 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?
Heh. Attaching to a process has the same effect as sending it a signal.
Any active system call is aborted and gdb traps it as it goes to
userspace. So by definition it's in running state when gdb gets it ...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.