pgsql 7.2.3 crash - Mailing list pgsql-hackers

From Laurette Cisneros
Subject pgsql 7.2.3 crash
Date
Msg-id Pine.LNX.4.44.0210081626400.32056-100000@visor.corp.nextbus.com
Whole thread Raw
Responses Re: pgsql 7.2.3 crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
A lot of different things going on but my perl program (whose backend crashed)
was doing a lot of insert into table as select * from another table for a
lot of different tables. I see triggers referenced here and it should be
noted that for one of the tables the triggers were first disabled (update
pg_class) and re-enabled after the inserts are done (or it takes forever).

The pgsql log shows:
...
2002-10-08 15:48:38 [18033]  DEBUG:  recycled transaction log file
00000052000000B1
2002-10-08 15:49:24 [28612]  DEBUG:  server process (pid 16003) was
terminated by signal 11
2002-10-08 15:49:24 [28612]  DEBUG:  terminating any other active server
processes
2002-10-08 18:49:24 [28616]  NOTICE:  Message from PostgreSQL backend:       The Postmaster has informed me that some
otherbackend       died abnormally and possibly corrupted shared memory.       I have rolled back the current
transactionand am       going to terminate your database system connection and exit.       Please reconnect to the
databasesystem and repeat your query.
 
...

A core file was found in <datadir>/base/326602604
and a backtrace shows:
(gdb) bt
#0  DeferredTriggerSaveEvent (relinfo=0x83335f0, event=0, oldtup=0x0,   newtup=0x8348150) at trigger.c:2056
#1  0x080b9d0c in ExecARInsertTriggers (estate=0x8333778,
relinfo=0x83335f0,   trigtuple=0x8348150) at trigger.c:952
#2  0x080c0f23 in ExecAppend (slot=0x8333660, tupleid=0x0,
estate=0x8333778)   at execMain.c:1280
#3  0x080c0dcd in ExecutePlan (estate=0x8333778, plan=0x83336f0,   operation=CMD_INSERT, numberTuples=0,
direction=ForwardScanDirection,  destfunc=0x8334278) at execMain.c:1119
 
#4  0x080c026c in ExecutorRun (queryDesc=0x826fd88, estate=0x8333778,
feature=3,   count=0) at execMain.c:233
#5  0x0810b2d5 in ProcessQuery (parsetree=0x826c500, plan=0x83336f0,
dest=Remote,   completionTag=0xbfffec10 "") at pquery.c:259
#6  0x08109c83 in pg_exec_query_string (   query_string=0x826c168 "insert into jobsequences select * from
rev_000_jobsequences", dest=Remote, parse_context=0x8242cd8) at
postgres.c:811
#7  0x0810abee in PostgresMain (argc=4, argv=0xbfffee40,   username=0x8202d59 "laurette") at postgres.c:1929
#8  0x080f24fe in DoBackend (port=0x8202c28) at postmaster.c:2243
#9  0x080f1e9a in BackendStartup (port=0x8202c28) at postmaster.c:1874
#10 0x080f10e9 in ServerLoop () at postmaster.c:995
#11 0x080f0c56 in PostmasterMain (argc=1, argv=0x81eb398) at
postmaster.c:771
#12 0x080d172b in main (argc=1, argv=0xbffff7d4) at main.c:206
#13 0x401e7177 in __libc_start_main (main=0x80d15a8 <main>, argc=1,   ubp_av=0xbffff7d4, init=0x80676ac <_init>,
fini=0x81554f0<_fini>,   rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff7cc)   at
../sysdeps/generic/libc-start.c:129


Thanks,

-- 
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
------------------------------
It's 10 o'clock...
Do you know where your bus is?



pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: [GENERAL] Large databases, performance
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Hot Backup