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 3E90A11D.DF534C32@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  (Lonni Friedman <lfriedman@vasoftware.com>)
List pgsql-general
Lonni Friedman wrote:
>
> On 04/04/03 14:32, Tom Lane wrote:
> >> i'm positive that there is a much more recent release.  this server is
> >> sadly, very poorly maintained by the customer.  do you feel that the
> >> segfaults generated in psql are blocking any possible solution to the
> >> pg_dump failures, or can you/I work on a solution for that indpendently of
> >> resolving the segfaults?
> >
> > Assuming that I've correctly diagnosed the segfault, it will only occur
> > if you try to print an extremely wide value in psql.  It's pretty easy
> > to avoid doing so, though.  For example, you could query for
> > LENGTH(bin_data) or a SUBSTRING() of it, instead of printing the whole
> > field value.  AFAIR, 7.2 does not have any optimizations that would
> > skip fetching the whole toasted value when it is the argument of one of
> > these functions, so "select length(bin_data) ..." should be just as
> > useful for checking for brokenness as "select bin_data ...".
>
> Hi Tom,
> Following your suggestion, i pinned down the following:
>
> sfee=# select LENGTH(bin_data) from artifact_file LIMIT 1 OFFSET 693;
> ERROR:  missing chunk number 1 for toast value 7685119
>
> However, what is very odd, is that I can view the entire contents of
> that row's particular bin_data column if i do a normal select:
> select bin_data from artifact_file LIMIT 1 OFFSET 693;
>
> and it completes with no errors.  After more testing, it appears that
> the 'select LENGTH(bin_data) ...' for any offset greater than or equal
> to 693 dies with the same 'missing chunk...' error.
>
> any suggestions on where to go from here?

From that I would assume that the row at offset 693 is totally intact
but the one at 694 is the one damaged. LIMIT reads one more row
internally than you asked for.

Get the key of the row at 694 (and others you might find) and continue
the work using those keys.


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: "Raymond O'Donnell"
Date:
Subject: Consecutive queries
Next
From: Lonni Friedman
Date:
Subject: Re: unable to dump database, toast errors