Hash collisions resolving

[GoogleCodeExporter]

Hi!

What steps will reproduce the problem?
1. Start the database 
2. Do this:
K1=16#d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609
f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436
c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6
a8839396f9652b6ff72a70.

K2=16#d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609
f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436
c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6
a8839396f965ab6ff72a70.

true = (K1=/=K2).

BK1= <<K1:1024>>.
BK2= <<K2:1024>>.

V=10.
cs_api_v2:write(BK1, V).
V=cs_api_v2:read(BK2).

V2=20.
cs_api_v2:write(BK2, V2).
V2=cs_api_v2:read(BK1).

What is the expected output? What do you see instead?
In this example I show the case when with different keys one can handle same 
value. It's happen due to md5-hash collisions. I understand that the case is 
rare, but it a time-bomb...

Do you plan to implement a hash collisions resolving?

What version of the product are you using? On what operating system?
svn-965

Original issue reported on code.google.com by serge.po...@gmail.com on 4 Aug 2010 at 10:31

[GoogleCodeExporter]

Right, up to now, the user is responsible to care about it, as we do not store 
the original key in the database and therefore cannot detect collisions. If we 
store the original key in each replica, we could add a collision test, but 
collisions are really rare and the test is almost always unnecessary.

Alternatively we could switch the hashing algorithm to SHA-2 or something with 
even less collisions.

Original comment by schin...@gmail.com on 4 Aug 2010 at 5:28

[GoogleCodeExporter]

> Right, up to now, the user is responsible to care about it
But user can't control this due to unknown (for him) procedure of key 
transformation.

>Alternatively we could switch the hashing algorithm to SHA-2 or something with 
even less collisions.
This is just hiding the problem, but not the solution.

Is your position on this issue strict? Or in the future mechanism for 
collisions resolving may be implemented?

Original comment by serge.po...@gmail.com on 5 Aug 2010 at 9:58

[GoogleCodeExporter]

You could put the unhashed key into the value and use the transaction mechanism 
to check whether there is a hash collision on this key. 

At the moment, I would say that the risk of a collision is very small and if 
you think that the risk is to high, you can place the unhashed key into the 
value to check for collisions.

Original comment by schu...@gmail.com on 6 Aug 2010 at 11:49

[GoogleCodeExporter]

Ok. Thanks for the response. 

Original comment by serge.po...@gmail.com on 6 Aug 2010 at 11:53

[GoogleCodeExporter]

Original comment by schin...@gmail.com on 12 Jan 2011 at 6:51

• Changed state: WontFix