Re: Trigger that spawns forked process
От | Douglas McNaught |
---|---|
Тема | Re: Trigger that spawns forked process |
Дата | |
Msg-id | m2wtq85d26.fsf@Douglas-McNaughts-Powerbook.local обсуждение исходный текст |
Ответ на | Re: Trigger that spawns forked process (Christopher Murtagh <christopher.murtagh@mcgill.ca>) |
Ответы |
Re: Trigger that spawns forked process
Re: Trigger that spawns forked process |
Список | pgsql-general |
Christopher Murtagh <christopher.murtagh@mcgill.ca> 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
В списке pgsql-general по дате отправления: