Hash collisions resolving
GoogleCodeExporter opened this issue · 5 comments
GoogleCodeExporter commented
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 commented
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 commented
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 commented
Ok. Thanks for the response.
Original comment by serge.po...@gmail.com
on 6 Aug 2010 at 11:53
GoogleCodeExporter commented
> 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 commented
Original comment by schin...@gmail.com
on 12 Jan 2011 at 6:51
- Changed state: WontFix