On Tue, May 10, 2005 at 04:02:59PM -0400, Christopher Murtagh wrote: > On Tue, 2005-05-10 at 11:11 -0500, Jim C. Nasby wrote: > > Well, LISTEN and NOTIFY are built into PostgreSQL > > (http://www.postgresql.org/docs/8.0/interactive/sql-notify.html). > > If the processes that you're trying to notify of the changes are > > connected to the database then this might be the easiest way to do > > what you're looking for. Setting up some form of replication, such > > as Slony, also comes to mind. But it's impossible to really make a > > recommendation without having a better idea of what you're doing. > > > > BTW, my understanding is that it's pretty easy to write a daemon > > in perl, and there are examples of how to do this floating around. > > Yes, I saw the LISTEN/NOTIFY stuff, and it could be interesting. As > to the replication, Slony won't do it for me, as it isn't the > database I want to replicate. Here's a basic description: > > I have 4 cluster nodes all running the same content management > software (home grown). When a change request comes in to one of them > (update to an XML document), it submits the new XML doc to the > database (which is the master repository of all content), then > performs an XSLT. Upon the new change, I want the database to > propagate the new result of the XSLT to the other nodes so that they > can pre-cache it (to avoid page loading latency). Why do you think Slony won't work for this? One way it could do it is to have an ON INSERT trigger that populates one or more tables with the result of the XSLT, which table(s) Slony replicates to the other servers. Cheers, D -- David Fetter david@xxxxxxxxxx http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
