Re: UPDATE: pg_dump fails due to invalid memory request

From: "Morgan Kita" <mkita(at)verseon(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-novice(at)postgresql(dot)org>
Subject: Re: UPDATE: pg_dump fails due to invalid memory request
Date: 2005-09-03 03:48:34
Message-ID: 08B420FF5BF7BC42A064212C2EB768801C10C2@neutron.verseon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

> 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 an invalid 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 to debug, but isn't it odd that I can select the data but not copy from it? I thought all that happens is that your output function is called which translates the custom datatype stored in the DB to a string for output. Well that seems to work through one but not the other? I guess I am just looking for suggestions on what to check for at this point. What is 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

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Lance Arlaus 2005-09-03 15:40:52 Privileged CUD Access via Stored Procs
Previous Message bob_a 2005-09-02 22:41:43 ERROR: 42P01: relation "<tableName" does not exist"