Re: unable to dump database, toast errors - Mailing list pgsql-general

On 04/03/03 14:01, Tom Lane wrote:
> Lonni J Friedman <lfriedman@vasoftware.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