Re: sblock state on FreeBSD 6.1
От | Jim C. Nasby |
---|---|
Тема | Re: sblock state on FreeBSD 6.1 |
Дата | |
Msg-id | 20060510215237.GW99570@pervasive.com обсуждение исходный текст |
Ответ на | Re: sblock state on FreeBSD 6.1 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: sblock state on FreeBSD 6.1
|
Список | pgsql-hackers |
On Wed, May 10, 2006 at 04:24:45PM -0400, Alvaro Herrera wrote: > Jim C. Nasby wrote: > > We tried reproducing this on a backup server. We haven't been able to > > wedge the system into a state where there's tons of sblock processes > > and nothing's getting done, but we were able to get some processes into > > sblock and get stack traces: > > > > #0 0x000000080135bd2c in recvfrom () from /lib/libc.so.6 > > #1 0x00000000004f9898 in secure_read () > > #2 0x00000000004fed7b in TouchSocketFile () > > #3 0x00000000004fee27 in pq_getbyte () > > #4 0x000000000055febf in PostgresMain () > > #5 0x000000000053a487 in ClosePostmasterPorts () > > #6 0x000000000053bab7 in PostmasterMain () > > #7 0x0000000000500436 in main () > > This stack trace doesn't make any sense. ClosePostmasterPorts is not > calling PostgresMain. And pq_getbyte is not calling TouchSocketFile, > which in turn isn't calling secure_read. So I see... that's rather disturbing... any idea why gdb would end up that confused? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: