Re: "incomplete startup packet" on SGI
От | David Rysdam |
---|---|
Тема | Re: "incomplete startup packet" on SGI |
Дата | |
Msg-id | 43A07B4C.6080505@ll.mit.edu обсуждение исходный текст |
Ответ на | Re: "incomplete startup packet" on SGI (David Rysdam <drysdam@ll.mit.edu>) |
Ответы |
Re: "incomplete startup packet" on SGI
|
Список | pgsql-general |
David Rysdam wrote: > Tom Lane wrote: > >> David Rysdam <drysdam@ll.mit.edu> writes: >> >> >>> Just finished building and installing on *Sun* (also >>> "--without-readline", not that I think that could be the issue): >>> Works fine. So it's something to do with the SGI build in particular. >>> >> >> >> More likely it's something to do with weird behavior of the SGI kernel's >> TCP stack. I did a little googling for "transport endpoint is not >> connected" without turning up anything obviously related, but that or >> ENOTCONN is probably what you need to search on. >> >> regards, tom lane >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: Don't 'kill -9' the postmaster >> >> >> >> > It's acting like a race condition or pointer problem. When I add > random debug printfs/PQflushs to libpq it sometimes works. > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > Not a race condition: No threads Not a memory leak: Electric fence says nothing. And it works when electric fence is running, whereas a binary that uses the same libpq without linking efence does not work.
В списке pgsql-general по дате отправления: