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