Re: unable to dump database, toast errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lonni J Friedman <lfriedman(at)vasoftware(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: unable to dump database, toast errors
Date: 2003-04-03 22:01:38
Message-ID: 13910.1049407298@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Lonni J Friedman <lfriedman(at)vasoftware(dot)com> writes:
> hrmmm...i'm not sure that the results i'm getting are matching up with
> your description of what should occur. This query:
> select * from artifact_file LIMIT 1 OFFSET 31;
> consistantly results in psql seg faulting. If I reduce or increase the
> OFFSET then the query succeeds.

[ thinks about it... ] Okay, I was being careless about considering
exactly when the value of the item would be accessed. In the above
example, it would seem that row 32 is corrupted in a way that's not
manifested unless we actually attempt to print individual field values;
the bad row can be pulled from the file and fed through the limit/offset
filter without noticing it's bad.

Exactly which field(s) of the bad row can you not select? I would
imagine that simple columns like integers couldn't cause a core dump.
Do the fields that are readable look plausible, or have they been
trashed too?

> But from what you're saying it sounds like i
> should be seeing a toast error as an indication of the bad data, and that
> isn't happening (at least not in the first 60 rows that i've selected so
> far).

It'd seem that this particular row is corrupted in a way that makes it
dump core before it gets to the TOAST table. Or it could be that the
main table row is fine and the problem is corruption in the TOAST data.
The toast errors you reported before are presumably coming from other
rows that have been damaged in different ways.

It'd be useful to get a stack trace out of the core dump, if you have
the tools to do that on the client's machine.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vlad Krupin 2003-04-03 22:13:44 Re: 'DROP INDEX' kills stored rpocedures
Previous Message Stephan Szabo 2003-04-03 21:58:17 Re: Multiple References on one Foreign Key