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

[Luís Soares]

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 ?

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