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

Ok now I know what was going on...

I was using the MACRO PG_GETARG_POINTER(0). From reading the manual on
this page: http://www.postgresql.org/docs/8.0/interactive/xtypes.html
and combining it with the example above, I made the wrong assumption
that it was calling pg_detoast_datum underneath. I now used the
preprocessor to figure out that it just returns a raw pointer.

So I am switching to the macro PG_GETARG_VARLENA_P(0)... does that seem
correct? The macro expansion appears to be correct, but I would just
apperciate some verification.

Thanks,
Morgan

-----Original Message-----
From: pgsql-novice-owner@postgresql.org
[mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Michael Fuhr
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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

On Sat, Sep 03, 2005 at 02:40:59PM -0700, Morgan Kita wrote:
> I was using the MACRO PG_GETARG_POINTER(0). From reading the manual on
> this page: http://www.postgresql.org/docs/8.0/interactive/xtypes.html
> and combining it with the example above, I made the wrong assumption
> that it was calling pg_detoast_datum underneath. I now used the
> preprocessor to figure out that it just returns a raw pointer.

The Complex type in that page's example has internallength = 16;
it's not a varlena type so it doesn't have to be detoasted.

Note the comments in the penultimate paragraph on that page regarding
variable-length types:

  The C functions operating on the data type must be careful to
  unpack any toasted values they are handed, by using PG_DETOAST_DATUM.
  (This detail is customarily hidden by defining type-specific GETARG
  macros.)

> So I am switching to the macro PG_GETARG_VARLENA_P(0)... does that seem
> correct? The macro expansion appears to be correct, but I would just
> apperciate some verification.

That macro is defined in fmgr.h as

  #define PG_GETARG_VARLENA_P(n) PG_DETOAST_DATUM(PG_GETARG_DATUM(n))

so I think it should work.  For my own varlena types I've been doing
something like the following to mimic the macros for the standard
types (see fmgr.h):

  #define DatumGetMytypeP(X)     ((mytype *)PG_DETOAST_DATUM(X))
  #define PG_GETARG_MYTYPE_P(n)  DatumGetMytypeP(PG_GETARG_DATUM(n))

With these macros, code can simply use PG_GETARG_MYTYPE_P(n) without
worrying about the detail of detoasting.

--
Michael Fuhr