SM == Scott Marlowe [EMAIL PROTECTED] writes:
SM Are you getting any output from the postgresql logs that would point to
SM backends dieing or anything like that? This sounds like a networking /
SM client problem to me.
Ok... well, I rebuilt the entire OS and postgres *without* the gcc
Opteron
This morning I came in to discover that my nightly pg_dump backup to a
remote server had failed. Both the server and the client are have
postgres 8.0.1 installed. Figuring it was just a fluke I ran the dump
again by hand and got the same error:
% pg_dump -h d01-prv -Fc -f mm.22-Mar-2005.dump
On Tue, 2005-03-22 at 10:36, Vivek Khera wrote:
This morning I came in to discover that my nightly pg_dump backup to a
remote server had failed. Both the server and the client are have
postgres 8.0.1 installed. Figuring it was just a fluke I ran the dump
again by hand and got the same
On Mar 22, 2005, at 11:53 AM, Ed L. wrote:
You might look into possible network-related issues. Maybe check
what is happening on the NICs (tx/rx errors? collisions?), see
if that gives any clues...
well, whaddya know: kernel log messages at the relevant times:
Mar 22 03:42:22 d01 kernel: bge0:
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
On Tuesday March 22 2005 9:36, Vivek Khera wrote:
While poking through the logs for these errors, I'm finding a
*lot* of broken pipe/unexpected EOF errors for this server but
for connections from other hosts as well, running reports.
those hosts still have the 7.4 client libraries.
You might
