Re: BUG #1061: message type 0x49 arrived from server while
От | Robert Creager |
---|---|
Тема | Re: BUG #1061: message type 0x49 arrived from server while |
Дата | |
Msg-id | 20040122204819.1d1314e8.Robert_Creager@LogicalChaos.org обсуждение исходный текст |
Ответ на | Re: BUG #1061: message type 0x49 arrived from server while idle (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
When grilled further on (Thu, 22 Jan 2004 22:19:44 -0500), Tom Lane <tgl@sss.pgh.pa.us> confessed: > Robert Creager <Robert_Creager@LogicalChaos.org> writes: > > What more information would you be looking for? > > Well, in the words of the old saw, if we knew what we were looking for > it wouldn't be research ... That's fine. The 'tone' of your e-mail led me to believe I wasn't providing something obvious, which I could believe. > > I'm sure we could solve it quickly if we could get a reproducible test > case, but it sounds like you are nowhere near being able to provide > that. I would suggest looking for context information: what else is > happening at the same time this happens? Multiple 'simultaneous' connections (through forking) is a possibility. I believe it was 4 child processes when this occurred the last time, but I'm not 100% sure. > > Another thing that would probably give enough information to solve it > is a trace of the connection from a TCP packet sniffer, for at least > a few packets leading up to the error message. Not sure if it's > practical to try to get one, but if you could it'd be great. Not a problem. Thankfully I have full control on this box, not the Solaris side though. And the box is dedicated to this database, so there shouldnb't be a ton of extra traffic either. Just the normal mis-configured network client broadcast jabber ;-) I should be able to figure out tcpdump enough to filter out all traffic except that between the two servers. Cheers, Rob -- 20:40:25 up 25 days, 10:27, 4 users, load average: 2.02, 2.02, 2.00
В списке pgsql-bugs по дате отправления: