Re: unable to dump database, toast errors

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