On Mon, 2005-05-09 at 17:07 -0400, Tom Lane wrote:
> Douglas McNaught <doug@mcnaught.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