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 по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: failure with pg_dump
Следующее
От: "Ed L."
Дата:
Сообщение: Re: failure with pg_dump