[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: [GENERAL] pg_ctl kill QUIT
From: Craig Ringer <ringerc () ringerc ! id ! au>
Date: 2012-07-30 11:08:55
Message-ID: 50166B47.3000605 () ringerc ! id ! au
[Download RAW message or body]
On 07/30/2012 05:52 PM, Venkat Balaji wrote:
> Hello Community,
>
> We have used "pg_ctlkill QUIT <PID>" to terminate one of the processes
> on the production database and the database went into recovery mode.
Did you intend to send SIGTERM (signal 15) instead of SIGQUIT (signal
3)? Signal 3 will be interpreted as a crash, it won't trigger a clean
backend shutdown.
If you are using any non-prehistoric version you should always use
pg_cancel_backend(...) to end a query, or pg_terminate_backend(...) to
ask a backend to terminate, rather than killing processes.
The database is supposed to go into recovery mode if it crashes or
terminates unexpectedly, like after a signal 3 (SIGQUIT) to a backend.
All the backends are terminated and when it starts back up it does crash
recovery then carries on happily.
If that is not what happened, please explain in more detail. Include:
- The text of the PostgreSQL log file from when you sent the signal.
This is important. If it's long, put it on pastebin.com or something and
link to it here.
- the exact text of any error messages you are getting
- Your postgresql version
- your OS and version
- why you tried to kill a backend / the postmaster / whaterver
- whether you know which process you killed and if so, what it was doing
- what steps you took after you killed the process
See: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Here's what should happen, from my 9.1.4 on my Fedora x64 box:
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
LOG: server process (PID 19178) exited with exit code 2
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted; last known up at 2012-07-30
17:22:10 WST
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: record with zero length at 8/151BB008
LOG: redo is not required
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
--
Craig Ringer
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/30/2012 05:52 PM, Venkat Balaji
wrote:<br>
</div>
<blockquote
cite="mid:CAFrxt0hWS7-X0X+svQAeJGsTZCR8wUofOHkfz3EY+amKSnjBUQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
Hello Community,
<div><br>
</div>
<div>We have used \
"<span>pg_ctl</span><span> </span><span>kill</span><span> QUIT \
<PID>" to terminate one of the processes on the
production database and the database went into recovery mode.</span></div>
</blockquote>
<br>
Did you intend to send SIGTERM (signal 15) instead of SIGQUIT
(signal 3)? Signal 3 will be interpreted as a crash, it won't
trigger a clean backend shutdown.<br>
<br>
If you are using any non-prehistoric version you should always use
pg_cancel_backend(...) to end a query, or pg_terminate_backend(...)
to ask a backend to terminate, rather than killing processes.<br>
<br>
The database is supposed to go into recovery mode if it crashes or
terminates unexpectedly, like after a signal 3 (SIGQUIT) to a
backend. All the backends are terminated and when it starts back up
it does crash recovery then carries on happily.<br>
<br>
If that is not what happened, please explain in more detail.
Include:<br>
<br>
- The text of the PostgreSQL log file from when you sent the signal.
This is important. If it's long, put it on pastebin.com or something
and link to it here.<br>
- the exact text of any error messages you are getting<br>
- Your postgresql version<br>
- your OS and version<br>
- why you tried to kill a backend / the postmaster / whaterver<br>
- whether you know which process you killed and if so, what it was
doing<br>
- what steps you took after you killed the process<br>
<br>
See:
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://wiki.postgresql.org/wiki/Guide_to_reporting_problems">http://wiki.postgresql.org/wiki/Guide_to_reporting_problems</a><br>
<br>
<br>
Here's what should happen, from my 9.1.4 on my Fedora x64 box:<br>
<br>
WARNING: terminating connection because of crash of another server
process<br>
DETAIL: The postmaster has commanded this server process to roll
back the current transaction and exit, because another server
process exited abnormally and possibly corrupted shared memory.<br>
HINT: In a moment you should be able to reconnect to the database
and repeat your command.<br>
LOG: server process (PID 19178) exited with exit code 2<br>
LOG: terminating any other active server processes<br>
WARNING: terminating connection because of crash of another server
process<br>
DETAIL: The postmaster has commanded this server process to roll
back the current transaction and exit, because another server
process exited abnormally and possibly corrupted shared memory.<br>
HINT: In a moment you should be able to reconnect to the database
and repeat your command.<br>
LOG: all server processes terminated; reinitializing<br>
LOG: database system was interrupted; last known up at 2012-07-30
17:22:10 WST<br>
LOG: database system was not properly shut down; automatic recovery
in progress<br>
LOG: record with zero length at 8/151BB008<br>
LOG: redo is not required<br>
LOG: autovacuum launcher started<br>
LOG: database system is ready to accept connections<br>
<br>
--<br>
Craig Ringer<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic