Re: unable to dump database, toast errors

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

On 04/03/03 14:01, Tom Lane wrote:
> 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.
>
> 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?

to better illustrate what i'm talking about:
# \d artifact_file
Table "artifact_file"
Column | Type | Modifiers

--------------+---------+--------------------------------------------------------
id | integer | not null default
nextval('artifact_file_id_seq'::text)
artifact_id | integer | not null
description | text |
bin_data | text |
filename | text | not null
filesize | integer | not null
filetype | text | not null
adddate | integer | not null default '0'
submitted_by | integer | not null
Primary key: artifact_file_pkey

i'm able to run this without any problems:
select
id,artifact_id,description,filename,filesize,filetype,adddate,submitted_by
from artifact_file LIMIT 1 OFFSET 31;

however, if i attempt to select just bin_data (which holds a 6MB M$-Word
doc) it attempts to dump it to screen for a few hundred lines, and then
segfaults.

>> 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.

at least in the above example it looks to me like its not the toast table.

> The toast errors you reported before are presumably coming from other
> rows that have been damaged in different ways.

i'll start searching for the next bad row, and see what turns up.

> 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.

i'm honestly not sure how to do this. the segfault is not producing a
core file that i can find. perhaps i'd need to tinker with ulimit?
even if i managed to get a core dump out of it, i don't really know how
to get a stack trace from it, so i'd need some guidance on that too.

thanks for your continued assistance.

-Lonni

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lincoln Yeoh 2003-04-04 03:58:42 Re: pgsql password when FreeBSD boots -- what's
Previous Message Robert Fitzpatrick 2003-04-04 03:35:28 Converting from dbase