[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: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: dev(at)archonet(dot)com, pgsql-general(at)postgresql(dot)org
Subject: [Re] Re: [Re] Re: [Re] Re: Unknown winsock error 10061while dumping a big database
Date: 2007-11-28 19:25:14
Message-ID: 0-39414678867-2674-2276354@CFGEM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


De : mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us
> "Cyril VELTER" <cyril(dot)velter(at)metadys(dot)com> writes:
> > The server have 4G of ram. But doing a search in the source code it does
not
> > seem that these values are used during a copy operation.
>
> They aren't. The "out of memory" complaint sounds more like it might be
> due to corrupt data, ie the olde scenario where a variable-width field's
> length word contains a ridiculously large value. I don't know how that
> would lead to a winsock error, though.

Yes this is very strange. The corruption scenario is plausible as the dump
stop at nearly the same place each time (it's a live database so the place is
not exactly the same).

Also, the database have been upgraded recently (2007-11-09) from 8.0.13 to
8.2.5 so I suppose the corruption have occured between this date and now ?

I have run the following query to get all record with one field over 10MB :

select
p2,length(p18155),length(p18154),length(p4065),length(p4083),length(p4020),lengt
h(p4074),length(p3857),length(p32402),length(p5512),length(p18175) from c2674
where length(p18155)>10000000 or length(p18154)>10000000 or
length(p4065)>10000000 or length(p4083)>10000000 or length(p4020)>10000000 or
length(p4074)>10000000 or length(p3857)>10000000 or length(p32402)>10000000 or
length(p5512)>10000000 or length(p18175)>10000000;

The biggest value is 28034379.

Is length() supposed to return the very high length in case of corruption ?

Is there anythning else i can do ?

Thanks,

Cyril VELTER

Table definition :

Column | Type | Modifiers
--------+-----------------------------+-----------
p2 | bigint |
p9 | boolean |
p3337 | integer |
p18155 | text |
p18154 | text |
p17561 | bigint |
p4065 | text |
p689 | bigint |
p43711 | integer |
p4083 | text |
p4020 | text |
p4029 | text |
p4218 | timestamp without time zone |
p4074 | text |
p45127 | bigint |
p3857 | text |
p7 | timestamp without time zone |
p6 | bigint |
p5 | timestamp without time zone |
p32402 | text |
p5512 | bytea |
p18175 | bytea |
p42542 | bigint |
p17562 | integer |
p4 | bigint |
Indexes:
"idx_2674_p2" UNIQUE, btree (p2)
"idx_2674_p17562" btree (p17562)
"idx_2674_p4" btree (p4)
"idx_2674_p4029" btree (p4029)
"idx_2674_p4218" btree (p4218)
"idx_2674_p42542" btree (p42542)
"idx_2674_p45127" btree (p45127)
"idx_2674_p5" btree (p5)
"idx_2674_p6" btree (p6)
"idx_2674_p689" btree (p689)
"idx_2674_p7" btree (p7)

Row count=1320365

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Dunstan 2007-11-28 19:32:09 Re: [HACKERS] plperl and regexps with accented characters - incompatible?
Previous Message Josh Harrison 2007-11-28 19:20:11 Re: Recheck condition