Обсуждение: Server crashing
My server is crashing on a delete statement. Here's the error message in the log file: LOCATION: ShutdownXLOG, xlog.c:3090 LOG: 00000: database system is shut down LOCATION: ShutdownXLOG, xlog.c:3104 LOG: 00000: database system was shut down at 2005-04-10 21:54:34 CDT LOCATION: StartupXLOG, xlog.c:2596 LOG: 00000: checkpoint record is at C/665D45E0 LOCATION: StartupXLOG, xlog.c:2628 LOG: 00000: redo record is at C/665D45E0; undo record is at 0/0; shutdown TRUE LOCATION: StartupXLOG, xlog.c:2653 LOG: 00000: next transaction ID: 109177; next OID: 92547340 LOCATION: StartupXLOG, xlog.c:2656 LOG: 00000: database system is ready LOCATION: StartupXLOG, xlog.c:2946 LOG: 00000: recycled transaction log file "0000000C00000063" LOCATION: MoveOfflineLogs, xlog.c:1656 LOG: 00000: recycled transaction log file "0000000C00000064" LOCATION: MoveOfflineLogs, xlog.c:1656 LOG: 00000: recycled transaction log file "0000000C00000065" LOCATION: MoveOfflineLogs, xlog.c:1656 WARNING: 25P01: there is no transaction in progress LOCATION: EndTransactionBlock, xact.c:1607 WARNING: 25P01: there is no transaction in progress LOCATION: EndTransactionBlock, xact.c:1607 ERROR: 42601: syntax error at end of input at character 77 LOCATION: yyerror, scan.l:565 WARNING: 25P01: there is no transaction in progress LOCATION: EndTransactionBlock, xact.c:1607 ERROR: 42601: syntax error at end of input at character 77 LOCATION: yyerror, scan.l:565 WARNING: 25P01: there is no transaction in progress LOCATION: EndTransactionBlock, xact.c:1607 WARNING: 25001: there is already a transaction in progress LOCATION: BeginTransactionBlock, xact.c:1545 ERROR: 42601: syntax error at end of input at character 77 LOCATION: yyerror, scan.l:565 WARNING: 25001: there is already a transaction in progress LOCATION: BeginTransactionBlock, xact.c:1545 ERROR: 42601: syntax error at end of input at character 77 LOCATION: yyerror, scan.l:565 LOG: 00000: received fast shutdown request LOCATION: pmdie, postmaster.c:1736 LOG: 00000: aborting any active transactions LOCATION: pmdie, postmaster.c:1743 FATAL: 57P01: terminating connection due to administrator command LOCATION: ProcessInterrupts, postgres.c:1955 FATAL: 57P01: terminating connection due to administrator command LOCATION: ProcessInterrupts, postgres.c:1955 FATAL: 57P01: terminating connection due to administrator command LOCATION: ProcessInterrupts, postgres.c:1955 FATAL: 57P01: terminating connection due to administrator command LOCATION: ProcessInterrupts, postgres.c:1955 LOG: 00000: shutting down LOCATION: ShutdownXLOG, xlog.c:3090 LOG: 00000: database system is shut down LOCATION: ShutdownXLOG, xlog.c:3104 I just turned off SQL command logging, stopped and started the process and now this command which worked just fine before is causing the DB to crash. I'm running Postgres 7.4.7 on Solaris 9 with PostGIS 0.9.1. The data I'm deleting is the parent table with many inherited child tables. Any ideas? -Don -- Donald Drake President Drake Consulting http://www.drakeconsult.com/ http://www.MailLaunder.com/ http://www.mobilemeridian.com/ 312-560-1574
Don Drake <dondrake@gmail.com> writes:
> My server is crashing on a delete statement.
> Here's the error message in the log file:
> LOG: 00000: received fast shutdown request
> LOCATION: pmdie, postmaster.c:1736
That says that something sent the postmaster a SIGINT signal.
I think it's highly unlikely that the DELETE statement did it.
regards, tom lane
Well, a vacuum on the entire DB seemed to have cleaned things up. No other user was logged into the server, and I certainly did not send the signal. I did clean up the serverlog file by truncating it ( > serverlog) while the DB was running, I don't think it liked that since it crashed the DB. I've done this on my Linux server many times and it never complained. I won't be doing that again. -Don On Apr 11, 2005 1:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Don Drake <dondrake@gmail.com> writes: > > My server is crashing on a delete statement. > > Here's the error message in the log file: > > > LOG: 00000: received fast shutdown request > > LOCATION: pmdie, postmaster.c:1736 > > That says that something sent the postmaster a SIGINT signal. > I think it's highly unlikely that the DELETE statement did it. > > regards, tom lane > -- Donald Drake President Drake Consulting http://www.drakeconsult.com/ http://www.MailLaunder.com/ http://www.mobilemeridian.com/ 312-560-1574
by Truncating the serverlog do you mean the data_log (as in my case) log file of the postgresql sever ?. If thats the file you truncated than i think its not a good habit..since you might need it at some point of time for some debugging purpose in production. You could use something like assuming there is a dummy file of 0 bytes in logs folder.. cp data_log data_log_$current_time cat logs/dummy_file>data_log gzip data_log_$current_time mv data_log_$current_time.gz logs/data_log_$current_time.gz Hope this helps Best Gourish Singbal On Apr 11, 2005 7:54 PM, Don Drake <dondrake@gmail.com> wrote: > Well, a vacuum on the entire DB seemed to have cleaned things up. > > No other user was logged into the server, and I certainly did not send > the signal. > > I did clean up the serverlog file by truncating it ( > serverlog) > while the DB was running, I don't think it liked that since it crashed > the DB. I've done this on my Linux server many times and it never > complained. I won't be doing that again. > > -Don > > On Apr 11, 2005 1:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Don Drake <dondrake@gmail.com> writes: > > > My server is crashing on a delete statement. > > > Here's the error message in the log file: > > > > > LOG: 00000: received fast shutdown request > > > LOCATION: pmdie, postmaster.c:1736 > > > > That says that something sent the postmaster a SIGINT signal. > > I think it's highly unlikely that the DELETE statement did it. > > > > regards, tom lane > > > > -- > Donald Drake > President > Drake Consulting > http://www.drakeconsult.com/ > http://www.MailLaunder.com/ > http://www.mobilemeridian.com/ > 312-560-1574 > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Best, Gourish Singbal