On 23/05/2011 9:37 AM, jun yang wrote:
> what we want to do is explore the ability to move the system to the
> architecture like below:
> some pg---message broker(qpid)---(web front and some collect data
> terminal,some business logic server,some system status monitor)
> when pg start it subscribe to qpid then process the message send to it.
> when pg is down,the important message is saved in message broker.
It's probably going to be a *lot* easier and more reliable to have
something sitting between Pg and the message broker. It can monitor Pg,
and unsubscribe from the broker when Pg is unavailable, then
re-subscribe when Pg becomes available again.
Putting it inside the PostgreSQL process space won't be especially easy,
because PostgreSQL doesn't support true stored procedures and doesn't
have any kind of built-in scheduler/event handler that can invoke them
without application involvement. Because of that, you'd probably have to
make significant changes to Pg's innards to make it work how you want.
There's been discussion of adding the ability for the postmaster to
start helper daemons, and if that were merged you could use a helper
started alongside the postmaster to do the work. Right now, though,
you're better off doing things how PgAgent etc do it, that is
out-of-process via a regular Pg connection.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
