On 2/3/2007 5:20 PM, Bruce Momjian wrote:
Jan Wieck wrote:
I don't have any such paper and the proof of concept will be the implementation of the system. I do however see enough resistance against this proposal to withdraw the commit timestamp at this time. The new replication system will therefore require the installation of a patched, non-standard PostgreSQL version, compiled from sources cluster wide in order to be used. I am aware that this will dramatically reduce it's popularity but it is impossible to develop this essential feature as an external module.

I thank everyone for their attention.

Going and working on it on your own doesn't seem like the proper
solution.  I don't see people objecting to adding it, but they want it
work, which I am sure you want too.  You have to show how it will work
and convince others of that, and then you have a higher chance it will
work, and be in the PostgreSQL codebase.


I think I have sufficiently detailed explained how this Lamport timestamp will be unique and ever increasing, with the nodes ID being used as a tie breaker. The only thing important for "last update wins" conflict resolution is that whatever timestamp you have associated with a row, the update you do to it must be associated with a later timestamp so that all other nodes will overwrite the data. If a third node gets the two updates out of order, it will do the second nodes update and since the row it has then has a later timestamp then the first update arriving late, it will throw away that information. All nodes in sync again.

This is all that is needed for last update wins resolution. And as said before, the only reason the clock is involved in this is so that nodes can continue autonomously when they lose connection without conflict resolution going crazy later on, which it would do if they were simple counters. It doesn't require microsecond synchronized clocks and the system clock isn't just used as a Lamport timestamp.

The problem seems to me that people want a full scale proof of concept for the whole multimaster replication system I'm planning instead of thinking isolated about this one aspect, the intended use case and other possible uses for it (like table logging). And we all know that that discussion will take us way behind the 8.3 feature freeze date, so the whole thing will never get done.

I don't want to work on this on my own and I sure would prefer it to be a default PostgreSQL feature. As said, I have learned some things from Slony-I. One of them is that I will not go through any more ugly workarounds in order to not require a patched backend. If the features I really need aren't going to be in the default codebase, people will have to install from patched sources.

Finally, again, Slony-I could have well used this feature. With a logical commit timestamp, I would have never even thought about that other wart called xxid. It would have all been sooo much easier.


# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [EMAIL PROTECTED] #

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to