Bug#35848: UUID() returns UUIDs with the wrong time
offset for time part in UUIDs was 1/1000 of what it should be. In other words, offset was off. Also handle the case where we count into the future when several UUIDs are generated in one "tick", and then the next call is late enough for us to unwind some but not all of those borrowed ticks. Lastly, handle the case where we keep borrowing and borrowing until the tick-counter overflows by also changing into a new "numberspace" by creating a new random suffix. mysql-test/r/func_misc.result: Show that time-part of UUIDs is correct now. mysql-test/t/func_misc.test: Show that time-part of UUIDs is correct now by replicating the C-code's resultin SQL. Results also decode to expect date-data on command-line (external validation). No test for unwinding of borrowed ticks as this a) is a race and b) depends on what timer we get. sql/item_strfunc.cc: correct offset for date/time-part of UUID. also make sure that when we counted into the future earlier (several UUIDs generated in same tick), we only give back as many "borrowed" ticks as we can without duplicating past timestamps. If our tick-counter overflows before we can give back, or if the system-clock is set back (by user or Daylight Saving Time), we create a new random suffix to avoid collisions and clear the tick-counter.
Showing
Please register or sign in to comment