Обсуждение: 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

> -----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 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
>