On Mon, 2005-05-09 at 17:07 -0400, Tom Lane wrote: > Douglas McNaught <doug@xxxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
