| From: | Christopher Murtagh <christopher(dot)murtagh(at)mcgill(dot)ca> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Douglas McNaught <doug(at)mcnaught(dot)org>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Trigger that spawns forked process |
| Date: | 2005-05-10 01:12:29 |
| Message-ID: | 1115687550.4795.10.camel@mafalda.corporateunderground.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, 2005-05-09 at 17:07 -0400, Tom Lane wrote:
> Douglas McNaught <doug(at)mcnaught(dot)org> 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 of those would be simpler and more robust than fork()ing
> > inside the backend.
>
> ... 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 forking plperl function that executes when the
transaction is done? How is one riskier than the other? Is there
something obvious I'm missing here?
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 | Douglas McNaught | 2005-05-10 01:16:29 | Re: Trigger that spawns forked process |
| Previous Message | Christopher Murtagh | 2005-05-10 01:07:40 | Re: Trigger that spawns forked process |