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