Re: [GENERAL] Shutting down a warm standby database in 8.2beta3

On Fri, Nov 17, 2006 at 11:40:36PM -0500, Tom Lane wrote:
> Stephen Harris <lists(at)spuddy(dot)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
> 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.

--

rgds
Stephen