On Fri, Nov 17, 2006 at 11:40:36PM -0500, Tom Lane wrote:
> Stephen Harris <[EMAIL PROTECTED]> 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
> kernels?

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.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to