On Feb 7, 8:12 pm, b...@momjian.us (Bruce Momjian) wrote:
> Jan Wieck wrote:
> > On 2/7/2007 10:35 PM, Bruce Momjian wrote:
> > > I find the term "logical proof of it's correctness" too restrictive. It
> > > sounds like some formal academic process that really doesn't work well
> > > for us.
>
> > Thank you.
My intuition is that it might be possible to prove that _nothing_ can
provide guaranteed ordering when there is disconnected operation.
However, I think that the clock based ordering Jan has described could
provide _probable_ ordering under disconnected operation. I can see
three variables in the equation that would determine the probability
of correctness for the ordering.
1) clock drift rate between disconnected clusters
2) disconnection time
3) transaction rate on the tables, or even rows involved
There are probably more. I think that if Jan implements what he's
described then a very interesting follow-up would be to do the
statistical analysis necessary to quantify the risk of incorrect
ordering while disconnected. (I've got x ms/ms relative clock drift,
and y tps. How long can I run disconnected before falling under
99.999% probability of correctly ordered transactions?)
> No, I _now_ understand the use case, but when the patch was posted, the
> use case was missing. I would like to see a repost with the patch, and
> a description of its use so we can all move forward on that.
An additional use case for an on-commit timestamp is in the analysis
of billing transactions in highly concurrent systems. For example,
imagine your billing period is monthly and you have transactions which
start before and end after the "end-of-month". Having the on-commit
timestamp for these transactions may help when attempting to reconcile
between transactions and account activities.
Andrew
