Hi!
>>>>> "Sander" == Sander Pilon <sander@stripped> writes:
>>
>> I can verify that this causes an error in 3.22.29, but it works
>> just fine with
>> 3.23.16.
>>
>> So does this warrant a new release of 3.22, or is the solution
>> to upgrade to 3.23 even though it isnt a fully stable system?
>>
>> I havent had any problems with 3.23.16, and as has been said on this list
>> before, it is equally or more stable than 3.22 for anything that
>> 3.22 did, but
>> maybe not production level on all new features (such as BDB transactions,
>> binary replication etc).
>>
>> SELECT 3-22.feature,3-22.stability,3-23.stability
>> FROM 3-22
>> LEFT JOIN 3-23
>> ON 3-22.feature = 3-23.feature;
>>
>> Dana
>>
Sander> IMO, a 3.22 patch should be released. Why? 3.22 is marketed as 'stable'
Sander> release and
Sander> contains reproducable lockups. These things do not belong in 'stable'
Sander> releases :)
Sander> So... you are saying that 3.32.16 is as stable as 3.22.32, as long as I dont
Sander> use any of the new
Sander> tricks?
Sasha has already answer quite extensively to this problem.
I just wanted to add that this problem + a workaround for 3.22 is
described in the MySQL manual, in the appendix 'Known errors and
design deficiencies in MySQL'. The reason for not updating MySQL 3.22
with the code that fixes this in 3.23 is that the fix was not trivial
and we don't want to add that much new code into 3.22 as it could make
this release less stable.
Basicly 3.23.x seams to be quite reliable now (except when it comes to
BDB and replication, which will need a few weeks to stabilize) and
it should be usable in production systems. We will release 3.22.17
later this week (which should fix most of the problems with the BDB
interface) and if this works ok we will release 3.23.18 next week as
beta as an indication that we believe it's reasonable stable :)
Regards,
Monty
