Chris Curvey <chris@chriscurvey.com> writes:
> And voila! Here is the backtrace:
> #0 0x00000000006ce317 in GetMemoryChunkSpace (pointer=0x347cc70) at
> mcxt.c:264
> #1 0x00000000006d3d56 in writetup_index (state=0x26fc530, tapenum=<value
> optimized out>, stup=<value optimized out>) at tuplesort.c:2924
> #2 0x00000000006d2af7 in dumptuples (state=0x26fc530, alltuples=0 '\000')
> at tuplesort.c:2068
> #3 0x00000000006d392f in puttuple_common (state=0x26fc530,
> tuple=0x7fff1e21d3b0) at tuplesort.c:1097
> #4 0x00000000006d3c4c in tuplesort_putindextuple (state=0x26fc530,
> tuple=<value optimized out>) at tuplesort.c:943
> #5 0x0000000000472cac in btbuildCallback (index=<value optimized out>,
> htup=0x26f4460, values=<value optimized out>, isnull=<value optimized out>,
> tupleIsAlive=1 '\001', state=0x7fff1e21d870) at nbtree.c:194
That is damn peculiar. The tuple handed to writetup_index would have
been copied just moments before in tuplesort_putindextuple, so there is
no way that GetMemoryChunkSpace ought to fail. If you do the run
several times over, do you get the exact same stack trace every time?
regards, tom lane
