[Re] Re: [Re] Re: [Re] Re: [Re] Re: Unknown winsock error 10061while dumping a big database

From: "Cyril VELTER" <cyril(dot)velter(at)metadys(dot)com>
To: dev(at)archonet(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-general(at)postgresql(dot)org
Subject: [Re] Re: [Re] Re: [Re] Re: [Re] Re: Unknown winsock error 10061while dumping a big database
Date: 2007-11-29 10:53:20
Message-ID: 0-39415439864-2674-2278504@CFGEM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

De : mailto:dev(at)archonet(dot)com
> Cyril VELTER wrote:
> >
> > Is length() supposed to return the very high length in case of corruption
?
>
> You'd have thought it would. The odd thing (if it is data corruption) is
> that you would expect to see something in the server logs about a
> failure to allocate 12345412234124 bytes of memory or some such. Whereas
> all you get is this winsock error.

I have another theory. The message printed by pg_dump :

"pg_dump: Error message from server: out of memory"

is printed in dumpTableData_copy (pg_dump.c) : write_msg(NULL, "Error message
from server: %s", PQerrorMessage(g_conn));

There are serveral places in libpq where the conn error might be set to "out
of memory". I've also discovered that the machine running pg_dump is pretty
tight in ram (256M) and that no swap file is active (oversight after a disk
upgrade). May be this error is simply pg_dump running out of memory and not the
server. This would also explain that the server only report a socket error
(though I would have expected WSAECONNRESET (10054) instead of WSAECONNREFUSED
(10061)).

The 8.0.13 pg_dump used to work just fine on the exact same machine. Maybe 8.2
pg_dump need more memory (or maybe a memory leak ?).

I'm running the dump again after adding some swap space and will monitor
memory usage.

What do you think ?

> > Is there anythning else i can do ?
>
> Could you try CREATE some_table AS SELECT * FROM c2674 WHERE ... to copy
> the large rows within the database. If that fails, the table is
> corrupted but you can identify the problem rows and work around them
> while you dump the data.

I will try that this week end if my theory prove wrong (I need to make disk
space available on the server for that, the table is 60GB).

Thanks,

Cyril

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Howard Cole 2007-11-29 10:54:41 Killing a session on windows
Previous Message Magnus Hagander 2007-11-29 09:48:22 Re: Linux v.s. Mac OS-X Performance