signal 10 (SIGBUS) using 7.2b2 Solaris
Having problems with the dB. Regression tests work, and an online
pg_dumpall from 7.1.3 to 7.2b2 worked fine. This dB is live on 7.1.3.
Using DBD::Pg in a script, although I check the actions through psql, with
the same results. Could this be me, or the dB?
version
------------------------------------------------------------------
PostgreSQL 7.2b2 on sparc-sun-solaris2.8, compiled by GCC 2.95.2
(1 row)
./configure --with-tcl --with-tclconfig=/proj/twolf/local/lib
--with-includes=/proj/twolf/local/include --with-libs=/proj/twolf/local/lib
--with-cassert --with-debug --enable-depend
2001-11-09 13:10:19 [20324] DEBUG: database system was shut down at
2001-11-09 13:10:09 MST
2001-11-09 13:10:19 [20324] DEBUG: checkpoint record is at 0/2ECED0A0
2001-11-09 13:10:19 [20324] DEBUG: redo record is at 0/2ECED0A0; undo
record is at 0/0; shutdown TRUE
2001-11-09 13:10:19 [20324] DEBUG: next transaction id: 1071; next oid:
4161708
2001-11-09 13:10:19 [20324] DEBUG: database system is ready
2001-11-09 13:10:26 [20327] DEBUG: connection: host=[local] user=robc
database=tassiv
2001-11-09 13:10:26 [20327] DEBUG: query: begin
2001-11-09 13:10:26 [20327] DEBUG: ProcessUtility: begin
2001-11-09 13:10:28 [20327] DEBUG: query: SELECT count(*) FROM files
WHERE name = 'hira2157620.fits' AND site_id = 't'
2001-11-09 13:10:28 [20327] DEBUG: query: INSERT INTO FILES ( site_id,
date, name, band ) VALUES ( 't', '2001-09-06 02:53:15', 'hira2157620.fits',
'I' )
2001-11-09 13:10:28 [20327] DEBUG: query: SELECT
currval('files_file_id_seq')
2001-11-09 13:10:28 [20327] DEBUG: query: INSERT INTO FILES ( site_id,
date, name, band ) VALUES ( 't', '2001-09-06 02:53:15', 'hvra2157620.fits',
'V' )
2001-11-09 13:10:28 [20327] DEBUG: query: SELECT
currval('files_file_id_seq')
2001-11-09 13:10:29 [20327] DEBUG: query: INSERT INTO observations (
file_id, ra, decl, mag, smag, x, y ) VALUES ( '536', '302.5686', 2.4190,
'11.1664177876566', '0.061', '201.580', '821.077' )
2001-11-09 13:10:29 [20321] DEBUG: server process (pid 20327) was
terminated by signal 10
2001-11-09 13:10:29 [20321] DEBUG: terminating any other active server
processes
2001-11-09 13:10:29 [20321] DEBUG: all server processes terminated;
reinitializing shared memory and semaphores
2001-11-09 13:10:29 [20329] DEBUG: database system was interrupted at
2001-11-09 13:10:19 MST
2001-11-09 13:10:29 [20329] DEBUG: checkpoint record is at 0/2ECED0A0
2001-11-09 13:10:29 [20329] DEBUG: redo record is at 0/2ECED0A0; undo
record is at 0/0; shutdown TRUE
2001-11-09 13:10:29 [20329] DEBUG: next transaction id: 1071; next oid:
4161708
2001-11-09 13:10:29 [20329] DEBUG: database system was not properly shut
down; automatic recovery in progress
2001-11-09 13:10:29 [20329] DEBUG: redo starts at 0/2ECED0E0
2001-11-09 13:10:30 [20329] DEBUG: ReadRecord: unexpected pageaddr
0/29CF6000 in log file 0, segment 46, offset 13590528
2001-11-09 13:10:30 [20329] DEBUG: redo done at 0/2ECF32C8
2001-11-09 13:10:33 [20329] DEBUG: database system is ready
Thank,
Rob
Robert Creager
Senior Software Engineer
Client Server Library
303.673.2365 V
303.661.5379 F
888.912.4458 P
StorageTek
INFORMATION made POWERFUL
"Creager, Robert S" <CreagRS@LOUISVILLE.STORTEK.COM> writes:
Having problems with the dB. Regression tests work, and an online
pg_dumpall from 7.1.3 to 7.2b2 worked fine. This dB is live on 7.1.3.
Using DBD::Pg in a script, although I check the actions through psql, with
the same results. Could this be me, or the dB?
A backend coredump is certainly not your fault. Please get a stack
backtrace from the core file and post it. Also please supply the schema
for the table that's accessed by the failing query.
./configure --with-tcl --with-tclconfig=/proj/twolf/local/lib
--with-includes=/proj/twolf/local/include --with-libs=/proj/twolf/local/lib
--with-cassert --with-debug --enable-depend
I believe those switches need to be --enable-cassert and --enable-debug,
not --with. This isn't causing your problem but it might impede
debugging it, since you've got a non-debug build.
regards, tom lane
Tom,
A backend coredump is certainly not your fault. Please get a stack
Never underestimate the stupidly of your users. I have a trigger function
which I had not re-compiled, just copied over. I thought of this when
dumping the schema. It's working now.
Sorry for the bandwidth.
Sheepishly yours,
Rob
Show quoted text
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, November 09, 2001 5:15 PM
To: Creager, Robert S
Cc: 'Bugs - PGSQL'
Subject: Re: [BUGS] signal 10 (SIGBUS) using 7.2b2 Solaris"Creager, Robert S" <CreagRS@LOUISVILLE.STORTEK.COM> writes:
Having problems with the dB. Regression tests work, and an online
pg_dumpall from 7.1.3 to 7.2b2 worked fine. This dB islive on 7.1.3.
Using DBD::Pg in a script, although I check the actions
through psql, with
the same results. Could this be me, or the dB?
A backend coredump is certainly not your fault. Please get a stack
backtrace from the core file and post it. Also please supply
the schema
for the table that's accessed by the failing query../configure --with-tcl --with-tclconfig=/proj/twolf/local/lib
--with-includes=/proj/twolf/local/include--with-libs=/proj/twolf/local/lib
--with-cassert --with-debug --enable-depend
I believe those switches need to be --enable-cassert and
--enable-debug,
not --with. This isn't causing your problem but it might impede
debugging it, since you've got a non-debug build.regards, tom lane
Import Notes
Resolved by subject fallback