Re: Sync Rep: Second thoughts

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