2011/9/16 Grzegorz Jaśkiewicz <gryzman@gmail.com>:
> 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
