Re: sblock state on FreeBSD 6.1 - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: sblock state on FreeBSD 6.1
Date
Msg-id 20060511173923.GJ30113@svana.org
Whole thread Raw
In response to Re: sblock state on FreeBSD 6.1  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: sblock state on FreeBSD 6.1
List pgsql-hackers
On Thu, May 11, 2006 at 12:09:56PM -0500, Jim C. Nasby wrote:
> Unfortunately, I suspect some of these were grabbed after the process
> had already moved past whatever was holding it in sblock.
>
> Here's the traces that we captured...
>
> Got 2 of these:
> #0  0x000000080135bd2c in recvfrom () from /lib/libc.so.6
> #1  0x00000000004f9898 in secure_read (port=0x834800, ptr=0x7cebe0,   len=8192) at be-secure.c:320

This is an idle backend waiting for the user.

> #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 suspect the rest of these probably happened after the sblock state had
> cleared, but here they are anyway in case I'm wrong. Also, I removed the
> 'incriminating evidence' from the query strings; there wasn't anything
> unusual about those queries, so I don't think it should matter.

The rest look like backends going through normal query functions...
There was one waiting for a lock but that's unlikely to be
significant...

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [PERFORM] Big IN() clauses etc : feature proposal
Next
From: Scott Marlowe
Date:
Subject: Re: [PERFORM] Big IN() clauses etc : feature proposal