Chris Curvey <chris@chriscurvey.com> writes:
> and, FWIW, here's another trace, which is NEARLY the same as the first one I
> posted, with the difference being a slightly different line number at #3. I
> will be quiet now and leave the brain trust to ponder. Let me know if there
> is anything else I can get for you guys.
> #0 0x00000000006ce317 in GetMemoryChunkSpace (pointer=0x292a0e0) at
> mcxt.c:264
> #1 0x00000000006d3d56 in writetup_index (state=0x2281670, tapenum=<value
> optimized out>, stup=<value optimized out>) at tuplesort.c:2924
It occurred to me that a simple explanation for a core dump there would
be if something had scribbled past the end of the preceding palloc
chunk. That would tend to clobber the "context" link of the palloc
chunk after it, which would send GetMemoryChunkSpace off into
never-never land following a trashed pointer.
That doesn't get us very much closer to a solution, but it does suggest
that you might learn something if you try this with an assert-enabled
build (configure --enable-cassert). Also, are there any contrib modules
or third-party add-on modules or home-brew C functions that you're using?
regards, tom lane