On Wed, Mar 24, 2010 at 5:28 PM, Arjen Lentz wrote:
> This test is as important as the above crash, because multi-engine
> transactions are something people will be using and thus relying on
> correctly working
I won't use this. We have enough problems when limited to one storage
engine. All of t
Paul McCullagh writes:
> On Mar 25, 2010, at 8:39 AM, Kristian Nielsen wrote:
>> Yes. This is simple enough to do with DBUG. Just insert code that
>> makes each
>> engine fail in their prepare() when the appropriate DBUG flag is set.
>>
>> Another test we need is to have similar code to crash th
>
> Ah, but the thing is, MySQL will never (as far as we know/guess) release
> 5.2. MySQL 5.2, 6.0, 5.4, they've all been officially cancelled! Next
> version
> currently is planned as MySQL 5.5. So we squeezed into the spare room :)
Then why not move away from their versioning numbers but always
#At lp:maria/5.2 based on revid:ser...@pisem.net-20100323092233-t2gwaclx94hd6exa
2751 Michael Widenius 2010-03-25
simple speed & space optimization:
- Avoid full inline of mark_trx_read_write() for many functions
- Avoid somewhat expensive tests for every write/update/delete ro
"Adam M. Dutko" writes:
> If we're always pulling from a mysql stable release and porting their
> features/patches why not always be a minor number above them?
>
> Say they release 5.2 ... we've added their patches from 5.2 but also added
Ah, but the thing is, MySQL will never (as far as we know
On Thu, Mar 25, 2010 at 3:47 AM, Kristian Nielsen
wrote:
> Colin Charles writes:
>
> > On 25 Mar 2010, at 02:09, Daniel Bartholomew wrote:
> >
> >> If so, my thinking is that the first 5.2 release will be called
> >> "5.2.1"
> >> and then go up from there.
> >
> >
> > This is the only logical way
Colin Charles writes:
> On 25 Mar 2010, at 02:09, Daniel Bartholomew wrote:
>
>> If so, my thinking is that the first 5.2 release will be called
>> "5.2.1"
>> and then go up from there.
>
>
> This is the only logical way forward
>
> We can then say "5.2.1 branched from MySQL 5.x" (for example)
>
Arjen Lentz writes:
> As a sideline of this, we need a test that verifies that the two-phase
> commit process actually works.
>
> This could be done by starting a transaction, doing some write in both
> XtraDB and PBXT, but set things up in such a way that a commit will
> fail on one - perhaps Pa
8 matches
Mail list logo
