Обсуждение: postgres dump cores
Hi, I'm using Postgres V 7.4.14 on HPUX 11.31 box. While doing a load test there was a core generated not sure why. Can you please help. Core was generated by `postgres'. Program terminated with signal 6, Aborted. #0 0x60000000c0587970:0 in kill+0x30 () from /usr/lib/hpux32/libc.so.1 (gdb) bt #0 0x60000000c0587970:0 in kill+0x30 () from /usr/lib/hpux32/libc.so.1 #1 0x60000000c0438e40:0 in raise+0x120 () from /usr/lib/hpux32/libc.so.1 #2 0x60000000c0548f50:0 in abort+0x170 () from /usr/lib/hpux32/libc.so.1 #3 0x4681890:0 in errfinish () at elog.c:476 #4 0x4685920:0 in elog_finish () at elog.c:849 #5 0x44f01b0:0 in s_lock_stuck () at s_lock.c:36 #6 0x44f02b0:0 in s_lock () at s_lock.c:94 #7 0x41dc800:0 in XLogInsert () at xlog.c:637 #8 0x41a91e0:0 in _bt_split () at nbtinsert.c:910 #9 0x41a6640:0 in _bt_insertonpg () at nbtinsert.c:507 #10 0x41a5060:0 in _bt_doinsert () at nbtinsert.c:141 #11 0x41b15f0:0 in btinsert () at nbtree.c:264 #12 0x4691010:0 in OidFunctionCall6 () at fmgr.c:1345 #13 0x41a16b0:0 in index_insert () at indexam.c:226 #14 0x43722e0:0 in ExecInsertIndexTuples () at execUtils.c:852 #15 0x42cd2f0:0 in CopyFrom () at copy.c:1699 #16 0x42c9770:0 in DoCopy () at copy.c:861 #17 0x4510ef0:0 in Proce ssUtility () at utility.c:480 #18 0x450e020:0 in PortalRunUtility () at pquery.c:793 #19 0x450d390:0 in PortalRunMulti () at pquery.c:857 #20 0x450c690:0 in PortalRun () at pquery.c:486 #21 0x45017c0:0 in exec_simple_query () at postgres.c:914 #22 0x4509d70:0 in PostgresMain () at postgres.c:2967 #23 0x447b6c0:0 in BackendFork () at postmaster.c:2564 #24 0x4476790:0 in BackendStartup () at postmaster.c:2207 #25 0x4476020:0 in ServerLoop () at postmaster.c:1119 #26 0x4472000:0 in PostmasterMain () at postmaster.c:897 #27 0x43c2d30:0 in main () at main.c:222 Thanks & Regards Rajaram J
"Rajaram J" <rajarj@hotmail.com> writes: > I'm using Postgres V 7.4.14 on HPUX 11.31 box. While doing a load test there > was a core generated not sure why. Can you please help. What sort of "load test" were you doing exactly? > #5 0x44f01b0:0 in s_lock_stuck () at s_lock.c:36 > #6 0x44f02b0:0 in s_lock () at s_lock.c:94 > #7 0x41dc800:0 in XLogInsert () at xlog.c:637 s_lock_stuck is not an impossible case, if you are stressing the system to say 100 or 1000 times past its design capacity. With a version as old as 7.4.x, I frankly wouldn't even bother to investigate it. Please do your experimentation on something recent, like 8.2.x ... regards, tom lane