Hi again,
Here are the most recent cores:
This one is from the postgres root directory. I'm not sure what the
circumstances behind the crash, but I was trying to kill the postmaster
with 'kill pid' because the database became unresponsive at around the
time the core was created.
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x2010d080.
#0 SpinAcquire (lockid=4) at ../../../include/storage/s_lock.h:119
119 __asm__("lock; xchgb %0,%1": "=q"(_res), "=m"(*lock):"0"(_res));
#0 SpinAcquire (lockid=4) at ../../../include/storage/s_lock.h:119
#1 0x9ebf6 in ShmemPIDDestroy (pid=13174) at shmem.c:452
#2 0xa36ac in ProcRemove (pid=13174) at proc.c:363
#3 0x8dbe7 in CleanupProc (pid=13174, exitstatus=9) at postmaster.c:1225
#4 0x8da35 in reaper (postgres_signal_arg=20) at postmaster.c:1140
#5 0xefbfdfdc in ?? ()
#6 0x9dc54 in proc_exit (code=0) at ipc.c:146
#7 0x8d9cb in pmdie (postgres_signal_arg=15) at postmaster.c:1115
#8 0xefbfdfdc in ?? ()
#9 0x8cbe7 in PostmasterMain (argc=5, argv=0xefbfdcb8) at postmaster.c:616
#10 0x4a0c2 in main (argc=5, argv=0xefbfdcb8) at main.c:93
This next one was created when I tried to vacuum the database using the
command line command 'vacuumdb --verbose --analyze ticket' where ticket is
the database name. This database contains several tables, one of which has
16k+ rows. The crash didn't leave pg_vlock in the database directory. Does
v6.5.1 still use pg_vlock? The last few NOTICEs were:
NOTICE: --Relation ticket--
NOTICE: Pages 324: Changed 1, Reapped 21, Empty 0, New 0; Tup 17048: Vac
13, Keep/VTL 0/0, Crash 0, UnUsed 35, MinLen 104, MaxLen 204; Re-using:
Free/Avail. Space 5100/1864; EndEmpty/Avail. Pages 0/11. Elapsed 0/0 sec.
NOTICE: Index i_ticketss: Pages 67; Tuples 17048: Deleted 13. Elapsed 0/1
sec.
NOTICE: Index ticket_pkey: Pages 103; Tuples 17048: Deleted 13. Elapsed
0/0 sec.
NOTICE: Rel ticket: Pages: 324 --> 324; Tuple(s) moved: 5. Elapsed 0/0
sec.
NOTICE: Index i_ticketss: Pages 67; Tuples 17048: Deleted 5. Elapsed 0/0
sec.
NOTICE: Index ticket_pkey: Pages 103; Tuples 17048: Deleted 5. Elapsed
0/0 sec.
NOTICE: AbortTransaction and not in in-progress state
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x2010d080.
#0 AllocSetReset (set=0x0) at aset.c:159
159 AllocBlock block = set->blocks;
#0 AllocSetReset (set=0x0) at aset.c:159
#1 0xda7ea in EndPortalAllocMode () at portalmem.c:938
#2 0x19227 in AtAbort_Memory () at xact.c:800
#3 0x19457 in AbortTransaction () at xact.c:1026
#4 0x19638 in AbortCurrentTransaction () at xact.c:1231
#5 0xa829c in PostgresMain (argc=5, argv=0xefbfd850, real_argc=5,
real_argv=0xefbfdcb8) at postgres.c:1550
#6 0x8e4ca in DoBackend (port=0x177000) at postmaster.c:1628
#7 0x8dfce in BackendStartup (port=0x177000) at postmaster.c:1373
#8 0x8d36e in ServerLoop () at postmaster.c:823
#9 0x8cbe7 in PostmasterMain (argc=5, argv=0xefbfdcb8) at postmaster.c:616
#10 0x4a0c2 in main (argc=5, argv=0xefbfdcb8) at main.c:93
And here's the one from the big database where one of the tables is 40k+
rows. On this one I was doing a 'select into temp t1 from ...' and it
crashed when I did 'select count(*) t1'. The query was from a Perl/DBI
script.
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x2010d080.
#0 0x1daa in nocachegetattr (tuple=0x1cc544, attnum=3,
tupleDesc=0x1e9100,
isnull=0xefbf9043 "") at heaptuple.c:546
546 off = att_addlength(off, att[i]->attlen, tp + off);
#0 0x1daa in nocachegetattr (tuple=0x1cc544, attnum=3, tupleDesc=0x1e9100,
isnull=0xefbf9043 "") at heaptuple.c:546
#1 0x3a6a4 in ExecEvalVar (variable=0x1cbf30, econtext=0x1cc4e8,
isNull=0xefbf9043 "") at execQual.c:295
#2 0x3b3b8 in ExecEvalExpr (expression=0x1cbf30, econtext=0x1cc4e8,
isNull=0xefbf9043 "", isDone=0xefbf9077 "\001r\205\001") at execQual.c:1207
#3 0x3aefa in ExecEvalFuncArgs (fcache=0x1cc7b8, econtext=0x1cc4e8,
argList=0x1cbf58, argV=0xefbf9078, argIsDone=0xefbf9077 "\001r\205\001")
at execQual.c:617
#4 0x3afd4 in ExecMakeFunctionResult (node=0x1cbf08, arguments=0x1cbf58,
econtext=0x1cc4e8, isNull=0xefbf9107 "", isDone=0xefbf90c7 "")
at execQual.c:698
#5 0x3b144 in ExecEvalOper (opClause=0x1cbee0, econtext=0x1cc4e8,
isNull=0xefbf9107 "") at execQual.c:870
#6 0x3b456 in ExecEvalExpr (expression=0x1cbee0, econtext=0x1cc4e8,
isNull=0xefbf9107 "", isDone=0xefbf9106 "\001") at execQual.c:1245
#7 0x3b505 in ExecQualClause (clause=0x1cbee0, econtext=0x1cc4e8)
at execQual.c:1312
#8 0x3b53d in ExecQual (qual=0x1cc0a0, econtext=0x1cc4e8) at execQual.c:1372
#9 0x3b86a in ExecScan (node=0x1cc158, accessMtd=0x405d0 <SeqNext>)
at execScan.c:142
#10 0x406ff in ExecSeqScan (node=0x1cc158) at nodeSeqscan.c:159
#11 0x39fbe in ExecProcNode (node=0x1cc158, parent=0x1cc158)
at execProcnode.c:262
#12 0x38f39 in ExecutePlan (estate=0x1cc228, plan=0x1cc158,
operation=CMD_DELETE, offsetTuples=0, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x1cc790) at execMain.c:908
#13 0x3871d in ExecutorRun (queryDesc=0x1cc210, estate=0x1cc228, feature=3,
limoffset=0x0, limcount=0x0) at execMain.c:339
#14 0xa8b27 in ProcessQueryDesc (queryDesc=0x1cc210, limoffset=0x0,
limcount=0x0) at pquery.c:333
#15 0xa8b8c in ProcessQuery (parsetree=0x1cb150, plan=0x1cc158, dest=Remote)
at pquery.c:376
#16 0xa6b3a in pg_exec_query_dest (
query_string=0xefbf92d8 "\n DELETE\n FROM T1\n WHERE
Count = 1", dest=Remote, aclOverride=0) at postgres.c:768
#17 0xa69d7 in pg_exec_query (
query_string=0xefbf92d8 "\n DELETE\n FROM T1\n WHERE
Count = 1") at postgres.c:656
#18 0xa83bc in PostgresMain (argc=5, argv=0xefbfd850, real_argc=5,
real_argv=0xefbfdcb8) at postgres.c:1647
#19 0x8e4ca in DoBackend (port=0x177000) at postmaster.c:1628
#20 0x8dfce in BackendStartup (port=0x177000) at postmaster.c:1373
#21 0x8d36e in ServerLoop () at postmaster.c:823
#22 0x8cbe7 in PostmasterMain (argc=5, argv=0xefbfdcb8) at postmaster.c:616
#23 0x4a0c2 in main (argc=5, argv=0xefbfdcb8) at main.c:93
Here's the output of 'SELECT VERSION()':
PostgreSQL 6.5.1 on i386-unknown-freebsd2.2.8, compiled by cc
Output of 'uname -a':
FreeBSD access.inet.co.th 2.2.8-STABLE FreeBSD 2.2.8-STABLE #0: Fri Feb 26 16:33:35
ICT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/ACCESS i386
Output of 'cc -v':
gcc version 2.7.2.1
Thanks for any help you can provide.
Anto.
