Re: Trigger that spawns forked process

On Tue, 2005-05-10 at 16:17 -0400, Tom Lane wrote:
> ... let's see, you already broke the backend there --- unless its normal
> setting of SIGCHLD is IGNORE, in which case munging it is unnecessary
> anyway ...

Here's my (probably all garbled) explanation: Essentially what that code
is a self-daemonizing perl wrapper. Setting SIGCHLD to IGNORE will
prevent zombie processes from hanging around, essentially
daemonizing/orphaning/forking the perl script.

> > unless ($pid) {
> > $cmd="your command here";
> > system "$cmd";
> > if ($? != 0) {
> > # handle errors here
> > }
> > exit;
> > }
>
> 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. :-)

> (An atexit hook in a backend
> process is entitled to suppose it is cleaning up a backend.) Also,
> exactly what is your "handle errors" step going to be?

Well, if my command fails for some reason, I can replace '#handle
errors' with something that notifies me (email, or by populating the
database, etc.).

> You don't get to reflect anything back into the database at that point.

That's ok, my $cmd might or might not have db connections in it, same
for the error checking script (which could be written in a totally
different language).

> The main reason why this is probably a bad idea is that your
> transaction is causing side-effects outside the database that cannot
> be undone if the transaction later rolls back. The general consensus
> of people who have looked at this is that it's safer to fire those
> operations after the transaction actually commits.

I should have stated that this will get used only by single auto-commit
transactions. Any rollbacks are essentially changes to the past and
aren't permitted. Instead if someone wanted to 'undo' a change, they
would re-submit a previous version. This way, I can keep my replication
code to very atomic things which makes it very simple to write and
maintain.

From my (somewhat limited experience) point of view, I think that this
plperlu script isn't much different from writing a daemon to receive
signals via NOTIFY. Instead the script is self daemonizing, and it will
always run (instead of a couple of NOTIFY's building up and only one
being sent), which is more in line with what I want.

Sorry, my explanation probably isn't very clear at all, I've been
writing talk material and my brain is in a totally different space. Feel
free to deliver any LARTs. :-)

Cheers,

Chris