Dmitry, AFAIK, since the only user of LCK_query_data with ordering clause is our transactions management code, the easiest way to fix this problem is to change lck_data to ULONG everywhere (and use static_assert to ensure that sizeof(TraNumber) == sizeof(ULONG) for the moment).
IMO, 64-bitness is not needed at the moment and it is probably better to conserve space in lock manager structures, because its size is limited to 4 GB in Firebird for the moment. We hit this limit a number of times. I can implement and commit a fix for this, as a separate change-set from my other changes, if this is what you want. Nikolay On 08/27/2014 03:58 PM, Dmitry Yemanov wrote: > 26.08.2014 00:29, Nikolay Samofatov wrote: >> When you converted transaction number from SLONG to TraNumber (ULONG) you >> didn't take into account >> that LCK_query_data returns SLONG and uses signed integers internally. > While there might be different solutions to this particular problem, I'm > wondering whether it would be generally useful to have the lock data > extended to 64-bit ints? Obviously, it would cost us four extra bytes > per every lock request, but supposedly the size issue could be worked > around if considered undesirable. > > > Dmitry > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
