Re: bzr commit into mysql-next-mr-rpl-merge branch (alfranio.correia:3202) WL#2775

[He Zhenxing]

Luís Soares wrote:
> On 10/26/2010 09:19 AM, Alfranio Correia wrote:
> > On 10/26/2010 05:02 AM, He Zhenxing wrote:
> >> Alfranio Correia wrote:
> >>> Hi Luis,
> >>>
> >>> I forgot to mention that we need to decide which collections will be
> executed with the
> >>> crash-slave options enabled and the periodicity.
> >>>
> >>> Please, provide a feedback on that.
> >>>
> >>
> >> What collections? Could you please provide more information about this?
> >
> > Hi Jasonh,
> >
> > Please, take a look at the following files in the patch
> >
> > mysql-test/collections/mysql-next-mr.crash-safe.daily
> > mysql-test/collections/mysql-next-mr.crash-safe.push
> > mysql-test/collections/mysql-next-mr.crash-safe.weekly
> >
> > We need to decide if we are going to push anything to main regarding that.
> > I don't think we should push this main but just keep it in our rpl-merge tree.
> > Running this new collections will take a lot of time. We even need to decide
> > what you are going to run in our tree because the valgrind's run takes 5 days.
> 
> I agree. Main trees tests should run with default options ON per push, ie,
> with replication data in files. However, I think we can make use of weekly
> runs to run a few tests with replication data stored in tables in the main
> trees.
> 
> > Is there any weekly runs for our tree? I don't think so and in such cases we
> > will need them.
> 
> Our team tree only runs the tests when there is a push to
> main (mysql-next-mr). Isn't that enough, instead of having
> weekly runs? It's not like a push to main happens on each
> and every day...
> 
> Nonetheless, as stated above, I would go for main + weekly
> runs for traditional table setups. Zhenxing, what do you think ?
> 

Fine for me, no strong opinions.

> Regards,
> Luís
> 
> >
> > Cheers.
> >
> >
> >>
> >>> Cheers.
> >>>
> >>> On 10/25/2010 04:12 PM, Luís Soares wrote:
> >>>> Hi,
> >>>>
> >>>> On 10/25/2010 12:15 PM, Alfranio Correia wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Please, find a new patch at
> http://lists.mysql.com/commits/121790.
> >>>>> I already pushed the patch to the mysql-next-mr.crash-safe.
> >>>>
> >>>> OK.
> >>>>
> >>>>> If there is anything left I will commit diffs.
> >>>>>
> >>>>> Cheers.
> >>>>>
> >>>>>
> >>>>> On 10/20/2010 11:05 AM, He Zhenxing wrote:
> >>>>>> Luís Soares wrote
> >>>>>>> On 10/20/2010 10:12 AM, Alfranio Correia wrote:
> >>>>>>>> Hi Jasonh, Luis,
> >>>>>>>>
> >>>>>>>> This is the only thing left to be fixed.
> >>>>>>>> As you know I will be off-line today but can you
> (Luis and Jasonh)
> >>>>>>>> discuss and tell
> >>>>>>>> me what to do? If not possible, let's have a call
> tomorrow.
> >>>>>>>
> >>>>>>> Lets have a quick call tomorrow then.
> >>>>>
> >>>>> I could not come up with a solution for this.
> >>>>>
> >>>>> If we try to execute an alter table when the server is starting
> up, we
> >>>>> get a segmentation fault.
> >>>>> This happens because several structures/objects are not ready at
> this
> >>>>> point.
> >>>>> And, the alter table code is too complex to extract the
> necessary
> >>>>> low-level functions without
> >>>>> the risky of missing anything.
> >>>>>
> >>>>> So I suggest to do what follows:
> >>>>>
> >>>>> PROPOSAL 1:
> >>>>> . Let's keep the code as it and file a bug report that I will
> be
> >>>>> addressed as a post-push fix.
> >>>>> . In this bug report we can try three different solutions:
> >>>>> 1. Call low-level functions to change the type of the engine
> thus
> >>>>> avoiding using the
> >>>>> parser.
> >>>>> 2. Figure out if the necessary objects can be created and use
> the
> >>>>> current idea.
> >>>>> 3. Move the call to another point in the code where the problem
> does
> >>>>> not happen.
> >>>>>
> >>>>> PROPOSAL 2:
> >>>>> . Try to fix the problem by using either (1), (2) or (3).
> >>>>>
> >>>>> I cannot promise an ETA and will need help in both proposals.
> >>>>
> >>>> I would go with proposal #1.
> >>>
> >>> ok.
> >>>
> >>>>
> >>>> Regards,
> >>>> Luís Soares
> >>>>
> >>>>> Cheers.
> >>>>>
> >>>>>>>
> >>>>>>
> >>>>>> OK
> >>>>>>
> >>>>>>>>
> >>>>>>>> Cheers.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 10/19/2010 06:14 AM, He Zhenxing wrote:
> >>>>>>>>> Alfranio Correia wrote:
> >>>>>>>>>>> R6. Do we allow changing repo table
> engine dynamically? If not
> >>>>>>>>>>> then I think
> Rpl_info_table::do_is_transactional() no need
> >>>>>>>>>>> to check the table every time, I think
> this can be checked
> >>>>>>>>>>> and saved the result when initializing
> the info table.
> >>>>>>>>>>
> >>>>>>>>>> Yes. It is possible to change it
> dynamically. A super user can
> >>>>>>>>>> always execute "alter table".
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I tent to think this is not a good idea to allow
> repo table engine
> >>>>>>>>> to be
> >>>>>>>>> changed at runtime, it might cause unexpected
> behavior, so I'd
> >>>>>>>>> strongly
> >>>>>>>>> suggest to disable this if you do not have any
> good use cases for
> >>>>>>>>> this
> >>>>>>>>> feature.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> 
>