Christopher Murtagh <christopher.murtagh@xxxxxxxxx> 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 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. 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. -Doug ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
