Re: unable to dump database, toast errors - Mailing list pgsql-general

From Jan Wieck
Subject Re: unable to dump database, toast errors
Date
Msg-id 3E916257.B23E0DB2@Yahoo.com
Whole thread Raw
In response to Re: unable to dump database, toast errors  (Lonni Friedman <lfriedman@vasoftware.com>)
Responses Re: unable to dump database, toast errors  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-general
Lonni Friedman wrote:
> yes, its got several other integer & text datatype fields.

Lonni,

just to let you know, we have all the time in the world and after all it
is your problem. So if you slow down the process by giving the
informaiton one drop at a time, we can certainly play that game. Just
don't blame us that it takes that long then.

Is there any of those other columns that could identify a single row
uniquely? If so, that could work as a key for this purpose.

If you have that, let's call it <keycolumn>. Then do a

    select <keycolumn> from artifact_file limit 1 offset 694.

The key you've got now will be most likely the row containing the
corrupted toast value. To check that it is the only one, let's say you
got <keyvalue> from the query above. Now do a

    select sum(length(bin_data)) from artifact_file
        where <keycolumn> != <keyvalue>

If that completes without an error, you found a way to identify the
damaged row without using LIMIT. I think Tom already explained what can
be done from here.


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-general by date:

Previous
From: Ken Harris
Date:
Subject: Re: chron scripts and pgsql
Next
From: "Dan Langille"
Date:
Subject: possible time change issue - known problem?