Re: Unable to dump database/table - Mailing list pgsql-bugs

From Krok
Subject Re: Unable to dump database/table
Date
Msg-id 416AA268.9090401@void.ru
Whole thread Raw
In response to Re: Unable to dump database/table  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unable to dump database/table  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Unable to dump database/table  (Andre Maasikas <andre@abs.ee>)
List pgsql-bugs
Yep !
You are right !

void=> \d users
                              Table "public.users"
      Column     |           Type           |             Modifiers
----------------+--------------------------+-----------------------------------
  id             | integer                  | default
nextval('u_serial'::text)
...
  passwd         | character varying(255)   |
...
void=> select max(length(passwd)) from users;
     max
-----------
  536870919
(1 row)

void=>  select id from users where length(passwd) > 255;
   id
-------
  25019
(1 row)

void=>

I've deleted this row and now backend process crashes with core dumped -
will keep trying to find out why

But how can this happen, that varchar(255) field became broken ?

Tom Lane wrote:
> Krok <krok@void.ru> writes:
>
>>pg_dump: dumping contents of table users
>>pg_dump: ERROR:  out of memory
>>DETAIL:  Failed on request of size 536870920.
>>pg_dump: SQL command to dump the contents of table "users" failed:
>>PQendcopy() failed.
>>pg_dump: Error message from server: ERROR:  out of memory
>>DETAIL:  Failed on request of size 536870920.
>
>
> Looks like corrupt data to me (specifically, a variable-width field
> with a ridiculous length word).
>
> You may care to consult the archives regarding methods for dealing with
> this sort of problem.  If you're lucky, there's only one bad row ...
>
>             regards, tom lane

--
With best regards,
Krok

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unable to dump database/table
Next
From: Tom Lane
Date:
Subject: Re: Unable to dump database/table