Re: sblock state on FreeBSD 6.1
От | Martijn van Oosterhout |
---|---|
Тема | Re: sblock state on FreeBSD 6.1 |
Дата | |
Msg-id | 20060511173923.GJ30113@svana.org обсуждение исходный текст |
Ответ на | Re: sblock state on FreeBSD 6.1 ("Jim C. Nasby" <jnasby@pervasive.com>) |
Ответы |
Re: sblock state on FreeBSD 6.1
|
Список | 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 по дате отправления: