From: Luís Soares
Date: October 25 2010 3:12pm
Subject: Re: bzr commit into mysql-next-mr-rpl-merge branch (alfranio.correia:3202)
 WL#2775
List-Archive: http://lists.mysql.com/commits/121831
Message-Id: <4CC59E4E.7060400@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.

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