Re: UPDATE: pg_dump fails due to invalid memory request
От | Morgan Kita |
---|---|
Тема | Re: UPDATE: pg_dump fails due to invalid memory request |
Дата | |
Msg-id | 08B420FF5BF7BC42A064212C2EB768801C10C3@neutron.verseon.com обсуждение исходный текст |
Ответы |
Re: UPDATE: pg_dump fails due to invalid memory request
|
Список | pgsql-novice |
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
В списке pgsql-novice по дате отправления: