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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
