Hello Emmanuel, Emmanuel Cecchet wrote: > I am happy to see that Postgres-R is alive again. The paper was written > in 07 (and published in 08, the review process is longer than a > CommitFest ;-)) and at the time of the writing there was no version of > Postgres-R available, hence the 'obsolete' mention referring to past > versions.
Understood. > I think that it is legitimate for users to expect more guarantees from a > replicated database than from a single database. Not knowing what happen > when a failure happens at commit time when some nodes are still active > in a cluster is not intuitive for users. I absolutely agree to that. However, it's lower priority for me. > I did not look at the source, but if Postgres -R continue to elaborate > on Bettina's ideas with writeset extraction and a certification > protocol, I think that it will be a bad idea to try to mix it with Sync > Rep (mentioned in another thread). I'm not quite sure what you mean by "certification protocol", there's no such thing in Postgres-R (as proposed by Kemme). Although, I remember having heard that term in the context of F. Pedone's work. Can you point me to some paper explaining this certification protocol? > If you delay commits, you will > increase the window for transactions to conflict and therefore induce a > higher abort rate (thus less scalability). This assumes that *all* types of transactions are unlikely to conflict. But there sometimes just are transactions with a very high probability for conflicts with other transactions. Applying optimistic locking (as the original Postgres-R algorithm does) cannot be efficient in such a case, because of lots of useless retries. (It could even lead to starvation of long running transactions, which always get aborted be shorter conflicting ones). > Certification-based > approaches have already multiple reliability issues to improve write > performance compared to statement-based replication, but this is very > dependent on the capacity of the system to limit the conflicting window > for concurrent transactions. What do you mean by "reliability issues"? Keeping the "conflicting window" as narrow as possibly certainly benefits performance, yes. But keeping the retry rate low also helps a lot (and influences the conflict window in turn). > The writeset extraction mechanisms have had > too many limitations so far to allow the use of certification-based > replication in production (AFAIK). What limitations are you speaking of here? > Good luck with Postgres-R. Thank you. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
