Skip site navigation (1) Skip section navigation (2)

Database in recovery mode

From: "Michael Richards" <michael(at)fastmail(dot)ca>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Database in recovery mode
Date: 2000-08-06 16:19:19
Message-ID: 398D9007.0000D1.92779@frodo.searchcanada.ca (view raw or flat)
Thread:
Lists: pgsql-bugs
Here are some log entries of the last dying words of postgres.
I've tried to reproduce this with limited success. Running this query 
the first time caused the database to croak. I killed all the 
processes in the STOP state ran ipcclean and restarted it. The server 
seems to run the query fine after that. 

I have to wait for the database to crash again to test more, but here 
were its dying words.

/usr/local/pgsql/bin/postmaster: ServerLoop:            handling 
reading 5
/usr/local/pgsql/bin/postmaster: ServerLoop:            handling 
reading 5
/usr/local/pgsql/bin/postmaster: ServerLoop:            handling 
writing 5
/usr/local/pgsql/bin/postmaster: BackendStartup: pid 41669 user 
equipment db equipment socket 5
/usr/local/pgsql/bin/postmaster child[41669]: starting with 
(/usr/local/pgsql/bin/postgres -d2 -B 128 -E -S 16384 -o /usr/local/pg
sql/home/logfile -v131072 -p equipment )
started: host=127.0.0.1 user=equipment database=equipment
InitPostgres
StartTransactionCommand
query: SELECT 0::numeric/a.exchangerate*b.exchangerate FROM 
currencies AS a, currencies AS b WHERE a.currencysymbol=''  AND b.curr
encysymbol='USD'
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: SELECT 0::numeric/a.exchangerate*b.exchangerate FROM 
currencies AS a, currencies AS b WHERE a.currencysymbol=''  AND b.curr
encysymbol='USD'
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: SELECT 
year,manufacturer,model,stocknumber,quantity,realprice,province,countr
y,id,pricecurrency FROM ad_trucks AS AD WHERE 
active='t' AND cat1=9 AND cat2=4576 AND UPPER(manufacturer) LIKE '%
KENWORTH%' AND year BETWEEN 1997 AND 2000
ProcessQuery
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: pid 41669 exited with 
status 139
Server process (pid 41669) exited with status 139 at Sun Aug  6 
11:48:07 2000
Terminating any active server processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 41668
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 41596
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 40299
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 40290
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 40288
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 40279
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 40277
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 40274
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 39964
/usr/local/pgsql/bin/postmaster: CleanupProc: sending SIGSTOP to 
process 39963
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: ServerLoop:            handling 
reading 5
/usr/local/pgsql/bin/postmaster: ServerLoop:            handling 
reading 5
/usr/local/pgsql/bin/postmaster: ServerLoop:            handling 
writing 5
The Data Base System is in recovery mode

Here is the bt on the core file it left behind:
bash-2.03# gdb -c postgres.core /usr/local/pgsql/bin/postgres
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging 
symbols found)...
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols 
found)...done.
Reading symbols from /usr/lib/libm.so.2...(no debugging symbols 
found)...done.
Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols 
found)...done.
Reading symbols from /usr/lib/libreadline.so.4...(no debugging 
symbols found)...done.
Reading symbols from /usr/lib/libncurses.so.5...(no debugging symbols 
found)...done.
Reading symbols from /usr/lib/libc.so.4...(no debugging symbols 
found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols 
found)...done.
#0  0x2828b1d0 in strncpy () from /usr/lib/libc.so.4
(gdb) bt
#0  0x2828b1d0 in strncpy () from /usr/lib/libc.so.4
#1  0x810da8b in fixedlen_like ()
#2  0x810db66 in textlike ()
#3  0x81316a0 in fmgr_c ()
#4  0x80a0af3 in ExecMakeFunctionResult ()
#5  0x80a0b37 in ExecEvalOper ()
#6  0x80a0e17 in ExecEvalExpr ()
#7  0x80a0ede in ExecQual ()
#8  0x80a134f in ExecScan ()
#9  0x80a6322 in ExecSeqScan ()
#10 0x809fb59 in ExecProcNode ()
#11 0x809ed55 in ExecutePlan ()
#12 0x809e2b6 in ExecutorRun ()
#13 0x80f9232 in ProcessQueryDesc ()
#14 0x80f92af in ProcessQuery ()
#15 0x80f7e54 in pg_exec_query_dest ()
#16 0x80f7d1d in pg_exec_query ()
#17 0x80f8c82 in PostgresMain ()
#18 0x80e1d0a in DoBackend ()
#19 0x80e189d in BackendStartup ()
#20 0x80e0ac1 in ServerLoop ()
#21 0x80e04c2 in PostmasterMain ()
#22 0x80aee43 in main ()
#23 0x8063385 in _start ()
(gdb) 

Hopefully this means more to someone on the list than me. I have a 
feeling it's something in the LIKE function (duh) that's being 
corrupted by a previous call or something (based on the fact I 
couldn't reliably reproduce the problem).

-Michael
_________________________________________________________________
     http://fastmail.ca/ - Fast Free Web Email for Canadians

pgsql-bugs by date

Next:From: Michael RichardsDate: 2000-08-06 16:38:04
Subject: Database in recovery mode
Previous:From: Tom LaneDate: 2000-08-06 02:46:22
Subject: Re: Temporary table error messages different to perm. tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group