Christopher Murtagh <[EMAIL PROTECTED]> writes:
> 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";
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 proces
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. Post
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-daem
On Tue, 2005-05-10 at 13:50 -0700, David Fetter wrote:
> Why do you think Slony won't work for this? One way it could do it is
> to have an ON INSERT trigger that populates one or more tables with
> the result of the XSLT, which table(s) Slony replicates to the other
> servers.
Because the nodes
On Tue, May 10, 2005 at 04:02:59PM -0400, Christopher Murtagh wrote:
> On Tue, 2005-05-10 at 11:11 -0500, Jim C. Nasby wrote:
> > Well, LISTEN and NOTIFY are built into PostgreSQL
> > (http://www.postgresql.org/docs/8.0/interactive/sql-notify.html).
> > If the processes that you're trying to notify
Christopher Murtagh <[EMAIL PROTECTED]> 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 a
On Tue, 2005-05-10 at 15:02, Christopher Murtagh wrote:
> On Tue, 2005-05-10 at 11:11 -0500, Jim C. Nasby wrote:
> > Well, LISTEN and NOTIFY are built into PostgreSQL
> > (http://www.postgresql.org/docs/8.0/interactive/sql-notify.html). If the
> > processes that you're trying to notify of the chang
On Tue, 2005-05-10 at 11:11 -0500, Jim C. Nasby wrote:
> Well, LISTEN and NOTIFY are built into PostgreSQL
> (http://www.postgresql.org/docs/8.0/interactive/sql-notify.html). If the
> processes that you're trying to notify of the changes are connected to
> the database then this might be the easies
On Mon, May 09, 2005 at 09:07:40PM -0400, Christopher Murtagh wrote:
> 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 tab
Christopher Murtagh <[EMAIL PROTECTED]> writes:
> On Mon, 2005-05-09 at 17:07 -0400, Tom Lane wrote:
>> ... not to mention it would avoid the risk of propagating
>> not-yet-committed changes.
> How's that? If I can notify a daemon that the change is committed, then
> why couldn't I write a forkin
Christopher Murtagh <[EMAIL PROTECTED]> 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
>>
On Mon, 2005-05-09 at 17:07 -0400, Tom Lane wrote:
> Douglas McNaught <[EMAIL PROTECTED]> writes:
> > 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 perio
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 even
Douglas McNaught <[EMAIL PROTECTED]> writes:
> 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
Christopher Murtagh <[EMAIL PROTECTED]> writes:
> No, I don't want the trigger to do any db stuff at all. Basically, I've
> got a content management system that is going to be split across a
> cluster. Upon an update submission from one of them, I want to replicate
> across the others (which can
On Mon, 2005-05-09 at 15:38 -0400, Tom Lane wrote:
> Christopher Murtagh <[EMAIL PROTECTED]> writes:
> > I would like to write a trigger or function that spawns a forked
> > process so that the transaction is considered 'complete' to the client,
> > but continues to perform more work.
>
> It's no
Christopher Murtagh <[EMAIL PROTECTED]> writes:
> I would like to write a trigger or function that spawns a forked
> process so that the transaction is considered 'complete' to the client,
> but continues to perform more work.
It's not very clear what you are hoping to have the forked process do,
I would like to write a trigger or function that spawns a forked
process so that the transaction is considered 'complete' to the client,
but continues to perform more work. I've been looking for examples to
steal^H^H^H^H^H learn from but have only found someone asking pretty
much the same question
19 matches
Mail list logo
