Re: Trigger that spawns forked process

Christopher Murtagh <christopher(dot)murtagh(at)mcgill(dot)ca> writes:
> I was given an example of how to spawn a forked process with plperlu,
> and it looks pretty simple and straightforward and exactly what I want:

> CREATE or REPLACE function somefunc() returns void as $$
> $SIG{CHLD}='IGNORE';

... 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 ...

> 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. (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? You don't get
to reflect anything back into the database at that point.

> This seems to be pretty trivial, and near fail-proof to me. my '$cmd'
> would then be a script that handles the replication of the cached file
> to the nodes (already written and tested). Why is a daemon more robust
> than this? (BTW, I ask out of ignorance, not out of arrogance).

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. (As an example,
this gives you an opportunity to retry the outside operations if *they*
fail, and in any case to keep some state information about whether the
outside-the-DB state is actually synced with inside-the-DB or not.)

regards, tom lane