Hi Jonas and Kristian,
The idea of a hybrid approach seems very good. My experience implementing
parallel apply on Tungsten leads me to believe that masters can supply
useful metadata for replication but cannot supply a definitive plan. There
are a number of reasons for this.
1. Slaves do not al
Hi, Kristian!
On Jul 04, Kristian Nielsen wrote:
> So then, the plan seems to be:
>
> 1. I remove the new calls from include/plugin.h, instead place them somewhere
> not part of a public API (maybe just "extern" declarations inside
> InnoDB/XtraDB, and whatever is needed to make it work correctly
Hi, Kristian!
On Jul 03, Kristian Nielsen wrote:
> >> === modified file 'storage/innobase/lock/lock0lock.cc'
> >> --- storage/innobase/lock/lock0lock.cc 2014-02-26 18:22:48 +
> >> +++ storage/innobase/lock/lock0lock.cc 2014-06-10 17:48:32 +
> >> @@ -1020,6 +1021,28 @@ lock_rec_has
Jonas Oreland writes:
> or perhaps a hybrid approach.
> master does "interesting" annotations
> slave takes decision based on annotations *and* own analysis
Agree.
There should be interesting possibilities to investigate.
One conplication for slave's own analysis is that for large transactions
On Fri, Jul 4, 2014 at 10:26 AM, Kristian Nielsen
wrote:
> Jonas Oreland writes:
>
> >
> > for row-based replication this seems quite "easy".
> >
> > for statement-based replication i image that you would have to add hooks
> > into the "real" code
> > after parsing has been performed, but befor
Sergei Golubchik writes:
> As you suggested on irc, it would make sense to make a smaller
> innodb/xtradb only fix in 10.0 and a more engine-friendly, with the new
> api, in 10.1
> Hmm, okay... When you put it this way, it does sound simpler.
> Allright, let's keep thd_report_wait_for() :)
Righ
2014-05-21 9:36 GMT+03:00 Stewart Smith :
> Otto Kekäläinen writes:
>> I've been thinking about this too, but I haven't formed an opinion yet
>> on what is the best way to introduce this. I assume there are many
>> debianists who don't like data collection, and server admins who
>> simply don't wa
Hi, Kristian!
On Jul 03, Kristian Nielsen wrote:
> Sergei Golubchik writes:
>
> > I'm kind of lost here. I really don't like requiring engines to do more
> > obligatory things, but I don't see a good way around it either.
>
> Agree, that's how I felt while trying to think of _any_ way to solve
Jan Lindström writes:
> 1) In innodb deadlock detection it is not certain that there is actually a
> deadlock, deadlock detection is done when a lock request is issued. At that
> point yes, we can see from lock manager that there is a deadlock, however
> if waiting transaction is rolled back e.g.
Jonas Oreland writes:
>
> for row-based replication this seems quite "easy".
>
> for statement-based replication i image that you would have to add hooks
> into the "real" code
> after parsing has been performed, but before the actual execution is
> started (and yes, i know that there is sometim
Hi Pablo,
The main goal of this task is developing an algorithm for test
selection. If you succeed at it but don't have time to create
interfaces, it should be very easy for us to fix it later. If, on the
other hand, you will end up with the complete system but without the
efficient enough al
Hello Elena,
I understand that the recall that we are achieving so far should still be
improved; nonetheless, since we are already in the second half of the
summer, I was wondering if we should spend some time designing the
interfaces for the implementation of the project; such that I can start
bui
12 matches
Mail list logo
