Re: Trigger that spawns forked process - Mailing list pgsql-general

From Douglas McNaught
Subject Re: Trigger that spawns forked process
Date
Msg-id m2vf5rc236.fsf@Douglas-McNaughts-Powerbook.local
Whole thread Raw
In response to Re: Trigger that spawns forked process  (Christopher Murtagh <christopher.murtagh@mcgill.ca>)
List pgsql-general
Christopher Murtagh <christopher.murtagh@mcgill.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

pgsql-general by date:

Previous
From: Christopher Murtagh
Date:
Subject: Re: Trigger that spawns forked process
Next
From: David Fetter
Date:
Subject: Re: Array manipulation/syntax question