On Thu, Apr 01, 2010 at 11:41:26PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> The transaction ID that is written to the log for a transaction is
> currently set by taking the lower 32 bits of the memory address of
> the ticket structure. This is not guaranteed to be unique as
> tickets comes from a slab and slots can be reallocated immediately
> after being freed. As a result, there is no guarantee of uniqueness
> in the ticket ID value.
> Fix this by assigning a random number to the ticket ID field so that
> it is extremely unlikely that duplicates will occur and remove the
> possibility of transactions being mixed up during recovery due to
> duplicate IDs.
I already noticed that you uses a random tid in your delayed logging
patches. But even a random number means we can get duplicate tids.
If we assign tids from a wrapping counter instead we can guarantee
that they are unique as long as we don't have more than UINT_MAX
transactions in the log, which is a limitation we could easily enforce.