Re: Trigger that spawns forked process

Christopher Murtagh <christopher(dot)murtagh(at)mcgill(dot)ca> writes:

> On Mon, 2005-05-09 at 17:01 -0400, Douglas McNaught wrote:
>> Why not have a client connection LISTENing and doing the
>> synchronization, and have the trigger use NOTIFY?
>>
>> Or, you could have the trigger write to a table, and have another
>> client periodically scanning the table for new sync events.
>>
>> Either one of those would be simpler and more robust than fork()ing
>> inside the backend.
>
> How is writing a daemon simpler than using something that could be done
> within Postgres? Forking is something that should be natural to Unix
> systems, I shouldn't need to write another application to do this. I
> don't see how a daemon would necessarily be more robust either.

Why do random code surgery on the backend, which needs to be utterly
robust and stable, when client-level solutions are just as easy and
much less dangerous?

It's kind of akin to the Linux principle of "don't do in the kernel
what you can do in userspace."

That's my philosophy, anyway. :)

-Doug