Обсуждение: Re: UPDATE: pg_dump fails due to invalid memory request

> 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

[Please don't change the Subject header when continuing the same
thread; it messes up some threaded displays.]

On Fri, Sep 02, 2005 at 08:48:34PM -0700, Morgan Kita wrote:
> >> 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.

What happens if you use "pg_dump --inserts" or if you issue a COPY
command directly?  Have you done what Tom suggested and tried to
get a strack trace on the backend?

> So obviously something is wrong with my code... but what should
> I do?

Post your data type's output function and we'll take a look.
The CREATE TYPE statement might also be useful.

> 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?

That seems odd to me; maybe Tom or somebody else who knows PostgreSQL
internals can explain why that might happen.

--
Michael Fuhr

On Sat, Sep 03, 2005 at 10:52:44AM -0600, Michael Fuhr wrote:
> On Fri, Sep 02, 2005 at 08:48:34PM -0700, Morgan Kita wrote:
> > So obviously something is wrong with my code... but what should
> > I do?
>
> Post your data type's output function and we'll take a look.
> The CREATE TYPE statement might also be useful.

It might be helpful to see the input function as well, along with
a test case.  That is, post enough C and SQL that somebody could
load into an empty database and duplicate the problem.

What version of PostgreSQL are you using?  I don't see that mentioned
in your earlier posts.

--
Michael Fuhr

On Sat, Sep 03, 2005 at 10:52:44AM -0600, Michael Fuhr wrote:
> On Fri, Sep 02, 2005 at 08:48:34PM -0700, Morgan Kita wrote:
> > 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?
>
> That seems odd to me; maybe Tom or somebody else who knows PostgreSQL
> internals can explain why that might happen.

In tests I see different behavior between SELECT and COPY if the
type's output function doesn't call PG_DETOAST_DATUM on its argument:
SELECT returns the correct data but COPY doesn't.  Have you neglected
to call PG_DETOAST_DATUM?

--
Michael Fuhr