On Fri, Nov 17, 2006 at 11:40:36PM -0500, Tom Lane wrote:
Stephen Harris <lists@spuddy.org> writes:
Why not, after calling fork() create a new process group with setsid() and
then instead of killing the recovery thread, kill the whole process group
(-PID rather than PID)? Then every process (the recovery thread, the
system, the script, any child of the script) will all receive the signal.
This seems like a good answer if setsid and/or setpgrp are universally
available. I fear it won't work on Windows though :-(. Also, each
It's POSIX, so I would suppose it's standard on most modern *nix
platforms. Windows... bluh. I wonder how perl handles POSIX::setsid()
on Windows!
backend would become its own process group leader --- does anyone know
if adding hundreds of process groups would slow down any popular
Shouldn't hurt. This is, after all, what using "&" in a command line
shell with job control (csh, ksh, tcsh, bash, zsh) does. Because you only
run one archive or recovery thread at a time (which is very good and very
clever) you won't have too many process groups at any instance in time.
[ thinks for a bit... ] Another issue is that there'd be a race
condition during backend start: if the postmaster tries to kill -PID
before the backend has managed to execute setsid, it wouldn't work.
*ponder* Bugger. Standard solutions (eg try three times with a second
pause) would mitigate this, but.... Hmm.

Another idea is to make the shutdown be more co-operative under control
of the script; eg an exit code of 0 means xlog is now available, code
if 1 means the log is non-existent (so recovery is complete) and an
exit code of 255 means "failure to recover; perform database shutdown".
In this way a solution similar to the existing trigger files ("recovery
complete") could be used. It's a little messy in that pg_ctl wouldn't
be used to shutdown the database; the script would essentially tell
the recovery thread to abort, which would tell the main postmaster to
shutdown. We'd have no clients connected, no child process running,
so a smart shutdown would work.



Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 35 | next ›
Discussion Overview
grouppgsql-hackers @
postedNov 17, '06 at 10:03p
activeNov 30, '06 at 9:40p



site design / logo © 2022 Grokbase