On Mon, May 09, 2005 at 09:07:40PM -0400, Christopher Murtagh wrote:
> On Mon, 2005-05-09 at 17:01 -0400, Douglas McNaught wrote:
> > 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.
>
> How is writing a daemon simpler than using something that could be done
> within Postgres? Forking is something that should be natural to Unix
> systems, I shouldn't need to write another application to do this. I
> don't see how a daemon would necessarily be more robust either.
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.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
