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

[Alfranio Correia]

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.

Is there any weekly runs for our tree? I don't think so and in such cases we
will need them.


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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
>