Hi all; I have been looking into how to ensure that synchronous replication, etc. could best be implimented. To date, I see only two options: incorporate the replication code into the database backend or have a separate "proxy" which handles the replication.
The main problem with incorporating the system into the backend process is that it limits the development to the 10-month timeframe between releases. The main advantage is that the planner could be used to spot queries which alter tuples and thus could "sort out" select queries. I am not sure if this could be done using a proxy approach if rules or user-defined functions were used. Also the proxy approach could be more flexible in that it could allow for different types of communications such as IP sharing which may not be desireable in the database backend. The easiest way of furthering the development of asynchronous replication proxies would be to break off the server-side network protocol handler into a library which would contain functions to bind to ports, listen, and pass messages back to the calling program. The library could then also be installed, but also be redistributable, so that developers could build these solutions. Also, if the protocol does not provide for "select" queries providing notification of affected tuples, an extension to handle that would be helpful and would allow for better load-ballancing. Best Wishes, Chris Travers ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
