Justin Pasher <justinp@xxxxxxxxxxxxxxxxxxx> writes: > Program terminated with signal 11, Segmentation fault. > #0 0x0827441d in MemoryContextAlloc () > (gdb) bt > #0 0x0827441d in MemoryContextAlloc () > #1 0x08274467 in MemoryContextStrdup () > #2 0x0826501c in database_getflatfilename () > #3 0x0826504e in database_getflatfilename () > #4 0x08265ec1 in AtEOXact_UpdateFlatFiles () > #5 0x080a9111 in RecordTransactionCommit () > #6 0x080a93a7 in CommitTransactionCommand () > #7 0x081a6c3b in autovac_stopped () > #8 0x081a75cd in autovac_start () > #9 0x081ae33c in ClosePostmasterPorts () > #10 0x081af058 in PostmasterMain () > #11 0x0816b3e2 in main () Hmm. This isn't very trustworthy for lack of debug symbols (what we're probably looking at are the nearest global function names before the actual locations). However, it strongly suggests that something is broken in the active memory context, and the most likely explanations for that are either a memory clobber (eg overrunning the requested size of a chunk) or CurrentMemoryContext pointing at a context that was already freed. The latter theory ties into the fact that it seems to be happening during transaction end. But any such bug of either type should have been found years ago given that development is invariably done with CLOBBER_FREED_MEMORY enabled. Alvaro, any thoughts? Remember this is 8.1.15. Justin, if you do feel like recompiling, please do so with original configure options (run pg_config to verify) and add --enable-cassert as well as --enable-debug. That might give us more to work with. 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
