On Wed, 2005-05-11 at 00:08 +0200, Martijn van Oosterhout wrote:
> On Tue, May 10, 2005 at 05:31:56PM -0400, Christopher Murtagh wrote:
> > > I'm not sure what happens when you do "exit" here, but I'll lay odds
> > > against it being exactly the right things.
> >
> > It ends the daemonized process, kinda like a wrapper suicide. :-)
>
> I think you have a problem here. PostgreSQL is a complete program,
> which use signal, atexit handlers, callback all or which fork()
> preserves. When your "little daemon" exits it may trigger all the code
> normally run on backend exit, you know, closing WAL files, etc...
>
> The rest of the program has no idea it's a forked process rather than a
> real one. Say the backend had a alarm() set and it goes off in your
> forked process. Havoc ensues...
Ok, I think I'm seeing the light here. Thanks for your input!
So, if I made a slight modification to my script to this instead:
CREATE or REPLACE function exec_test() returns void as '
unless (defined ($pid=fork)) {
die "cannot fork: $!";
}
unless ($pid) {
$cmd="/path/to/some/script.pl";
exec "$cmd";
}
RETURN;
' language plperlu;
Then the exec'd $cmd shouldn't inherit any of the signals or atexit
handlers. My script.pl can handle any errors it encounters (other than
not being executed of course, but I can live with that), and this way I
don't have to write a daemon that polls listening for a NOTIFY.
Is this less objectionable? Again, thanks to all for your input and
feedback, I really do appreciate it.
Cheers,
Chris
--
Christopher Murtagh
Enterprise Systems Administrator
ISR / Web Service Group
McGill University
Montreal, Quebec
Canada
Tel.: (514) 398-3122
Fax: (514) 398-2017
