> This looks like a pretty standard data-corruption situation: you've got
> a variable-width field somewhere with a ridiculous value in its length
> word. If you trawl the PG mail list archives you'll find plenty of
> examples and discussions about how to triangulate on the bad row(s) and
> get rid of them.
Ok after a bunch of testing I have discovered it isn't data corruption.
>> Now the only thing I can think of is that this particular table has 2
>> custom data types that are both toastable.
> [ raised eyebrow... ] Then it could also be a symptom of a garden
> variety bug in your custom datatype code. Have you tried getting
> a stack trace from errfinish() to see exactly where the complaint
> is being raised?
Bingo it is the custom datatype code. The curious things is this... When I do the dump it calls COPY... which balks on
aninvalid memory request. However, when I select the same rows that cause pg_dump to crash, I have absolutely no
problem.I have checked the output from the select statements and the data is identical to what went in.
So obviously something is wrong with my code... but what should I do? Obviously I will need to do more testing and try
todebug, but isn't it odd that I can select the data but not copy from it? I thought all that happens is that your
outputfunction is called which translates the custom datatype stored in the DB to a string for output. Well that seems
towork through one but not the other? I guess I am just looking for suggestions on what to check for at this point.
Whatis odd is that it isn't all rows either. Just certain ones... Ack totally confused in the world of rdbms I am!
Thanks,
Morgan
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
