Thread: Re: UPDATE: pg_dump fails due to invalid memory request

Hehe, funny thing is I realized that after I went home last night... For
some reason I took out my calls to PG_DETOAST_DATUM at some point... I
havn't a clue as to why, but oh well.

I need to go test this to verify, but I am 90% sure that is the problem.

Can someone explain to me why one works and not the other without
PG_DETOAST_DATUM?

Also can someone tell me how to easily tell how much data for a
particular table is being toasted?

Thanks guys!

Morgan

-----Original Message-----
From: Michael Fuhr [mailto:mike@fuhr.org]
Sent: Saturday, September 03, 2005 1:05 PM
To: Morgan Kita
Cc: Tom Lane; pgsql-novice@postgresql.org
Subject: Re: [NOVICE] UPDATE: pg_dump fails due to invalid memory
request


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

On Sat, Sep 03, 2005 at 01:48:49PM -0700, Morgan Kita wrote:
> Can someone explain to me why one works and not the other without
> PG_DETOAST_DATUM?

I don't know, but I'd guess that SELECT does some intermediate
processing that detoasts the data before it gets to the type's
output function.  Maybe one of the developers will explain what's
happening.

> Also can someone tell me how to easily tell how much data for a
> particular table is being toasted?

Look at the sizes of the table and its toast table.  If your
statistics are up to date on both, then a query like the following
should work:

SELECT c.relpages AS tablepages, t.relpages AS toastpages
FROM pg_class AS c JOIN pg_class AS t ON t.oid = c.reltoastrelid
WHERE c.relname = 'tablename';

See also the contrib/dbsize module (which will move into the standard
backend in 8.1).

--
Michael Fuhr

Michael Fuhr <mike@fuhr.org> writes:
> On Sat, Sep 03, 2005 at 01:48:49PM -0700, Morgan Kita wrote:
>> Can someone explain to me why one works and not the other without
>> PG_DETOAST_DATUM?

> I don't know, but I'd guess that SELECT does some intermediate
> processing that detoasts the data before it gets to the type's
> output function.  Maybe one of the developers will explain what's
> happening.

printtup() in src/backend/access/common/printtup.c forcibly detoasts
toasted datums in order to avoid memory leaks.  I'm not sure this is
still necessary.  COPY used to do something similar, but now it prefers
to call datatype-specific functions in a short-term memory context
that it can reset after every tuple.

[ this whole thread seems very far off topic for -novice, by the by. ]

            regards, tom lane