From: | Christopher Murtagh <christopher(dot)murtagh(at)mcgill(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Trigger that spawns forked process |
Date: | 2005-05-09 20:13:24 |
Message-ID: | 1115669604.7811.4.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2005-05-09 at 15:38 -0400, Tom Lane wrote:
> Christopher Murtagh <christopher(dot)murtagh(at)mcgill(dot)ca> 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,
> but if it's supposed to be another backend, forget it --- won't work.
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 happen in pseudo real time). So, basically
the DB is the master, once it makes an update, it will spawn a process
to the syncronization (all of this code is written). I just don't want
the initial update process to wait for replication to finish (which is
only a second or two under normal load). I could write a daemon that
would sit an listen to these replication requests, but that just seems
to be more complex than I need.
Cheers,
Chris
--
Christopher Murtagh
Enterprise Systems Administrator
ISR / Web Service Group
McGill University
Montreal, Quebec
Canada
Tel.: (514) 398-3122
Fax: (514) 398-2017
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2005-05-09 20:32:27 | Re: WHERE |
Previous Message | Dann Corbit | 2005-05-09 20:11:03 | Re: WHERE |