Chris Curvey <chris@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
