Re: Expanded Objects and Order By

I have a size/flatten callback setup (and they are very careful not to write outside their boundaries), so that’s all OK.
Since you’re not seeing anything “aha” in the error pattern, I’ll go back to the mats on memory… is there a good page on valgriding postgresql? I thought the memory manager papered over things so much that valgrind couldn’t see what was going on under the covers.

Thanks!

P

> On Jan 18, 2016, at 8:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
>> So, I've added support for converting postgis in-memory objects into
>> expanded outputs, and have overwritten the usual
>> lwgeom_to_gserialized() function with one that creates an expanded
>> object. I haven't done anything to actually handle expanded objects on
>> input, but as I understand it, that's fine, everything is supposed to
>> work as normal when handed expanded objects. And thus far, that has
>> been true, almost all regression tests work fine.
>
> Hmm ... you do need to be able to flatten them again. In the given
> example, the parser is going to want to form a Const node whose Datum
> value is a geometry object, and that Const node needs to be copiable
> by copyObject(), which means datumCopy() has to work, and if you look
> at that it will exercise EOH_get_flat_size/EOH_flatten_into when the
> input routine originally produced an expanded object.
>
> The error message is very strange; it's hard to see how toying with the
> internal representation of Consts could cause that. I think the
> hypothesis of a memory clobber is stronger than you give it credit for,
> especially since you see the behavior changing for seemingly unrelated
> reasons. Valgrind might be a useful tool here.
>
> regards, tom lane