Re: unable to dump database, toast errors

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Lonni Friedman <lfriedman(at)vasoftware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: unable to dump database, toast errors
Date: 2003-04-07 11:34:47
Message-ID: 3E916257.B23E0DB2@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ben-Nes Michael 2003-04-07 11:59:19 deferrable update expected soon ?
Previous Message Ken Harris 2003-04-07 11:31:20 Re: chron scripts and pgsql