Re: failure with pg_dump
От | Vivek Khera |
---|---|
Тема | Re: failure with pg_dump |
Дата | |
Msg-id | c57074e5cf486bafb1dd869f43b3ae35@kcilink.com обсуждение исходный текст |
Ответ на | Re: failure with pg_dump (Scott Marlowe <smarlowe@g2switchworks.com>) |
Список | pgsql-general |
On Mar 22, 2005, at 11:47 AM, Scott Marlowe wrote: >> The same config on the old box with Pg 7.4.7 worked flawlessly for >> running reports and dumps. Another issue is that the 8.0 server is >> noticeably slower than the 7.4 with identically (translated to 8.0 >> style) configs. > > IS there a difference in the infrastructure for this server? Like > firewalls and routing? > Nope. I actually pulled the ethernet wire from the dead box and plugged it into this one :-) The IP number is different by 1 bit. That's pretty much the only difference in the old and new boxes other than the move to Pg 8.0.1. > Also, is it vacuum / analyzed often? Poor stats will cause the server > to run slower. > Yes, vacuum analyze regularly. The query plans seem identical except the cost estimates are a bit different in number of rows returned. The choice of plan remains the same... > > > Are you getting any output from the postgresql logs that would point to > backends dieing or anything like that? This sounds like a networking / > client problem to me. My only guess is that a bug in gcc when optimizing for opteron, so I'm rebuilding the kernel and libraries of the base OS without those optimizations to see what happens. I know the clients are not having problems since they've been stable for a long time. I'm guessing nobody else is seeing arbitrary connection drops in 8.0.1, particularly on FreeBSD 5.4-PRERELEASE :-( Funny thing is that the pg_dump worked yesterday... Vivek Khera, Ph.D. +1-301-869-4449 x806
В списке pgsql-general по дате отправления: