From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | Morgan Kita <mkita(at)verseon(dot)com>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: UPDATE: pg_dump fails due to invalid memory request |
Date: | 2005-09-04 22:45:57 |
Message-ID: | 9189.1125873957@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Michael Fuhr <mike(at)fuhr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-09-04 22:49:37 | Re: problems when comparing text with special chars |
Previous Message | Jan Danielsson | 2005-09-04 18:01:47 | Last Id? |