2011/9/16 Grzegorz Jaśkiewicz <gryzman@xxxxxxxxx>: > Is anyone actually working on Postgres-R ? Last git commit was in January 2011. > What are the chances of it getting integrated with the core, which it > is probably targeted for ? > > If I picked it up, and tried to make usable for my own needs - instead > of implementing trigger/log (slony like) multi master async on my own > (other opensource ones are no use to me, or didn't perform well during > tests), > how much work is there to be done ? > > Lastly, is PostgresR async or sync MM replication ? According to wikipedia, postgres-r is synchronous. FWIW, I'm pretty skeptical that any MM replication solution will get adopted in core unless it is developed in concert with the community. Most MM products tend to be niche solutions with crippling downsides that make them not suitable for general use. Asynchronous MM rep in particular is totally incompatible with SQL since it breaks transaction guarantees. Postgresql replication is currently very much 'one way', and even if you could somehow work it so that multiple backends could server data modifying queries, I really wonder what the technical benefit of doing that would be -- what's wrong with putting a pgbouncer-ish front end(s) between the application and the server that can promote synchronously masters and redirect traffic? Extra intelligence could be put into that layer that could interleave certain types of queries for parallel execution The ndb approach to clustering really complex and not necessarily a good model to emulate IMO. The biggest weaknesses around postgresql replication are dealing with syncing standbys to a new master after promotion -- solve that problem well and after getting sync rep latency down as much as reasonably possible, and you could see some amazing stuff. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
