Hi Bar, Eugene,
I think that the rdiff file needs to be removed altogether. I misread
the test that it was converting from utf8, while it was actually
converting from ascii.
In my opinion, we do need several kinds of tests in this area:
* Changing from utf8mb3 to utf8mb4, with ALGORITHM=INSTANT
Hi.
23.04.2019, 16:49, "Alexander Barkov" :
> Hi,
>
> It seems I forgot to record the rdiff file.
>
> On 4/23/19 4:55 PM, Eugene Kosov wrote:
>> Hello, Marko, Alexander.
>>
>> 23.04.2019, 15:37, "Marko Mäkelä" :
>>> Bar, thank you for the revision.
>>>
>>> I ran all tests and found a
Hi Marko,
Thanks for your review.
On 4/23/19 4:37 PM, Marko Mäkelä wrote:
Bar, thank you for the revision.
I ran all tests and found a regression for ROW_FORMAT=REDUNDANT, in
the test innodb.instant_alter_charset,redundant. We should allow any
extension of VARCHAR maximum length (in bytes)
Hi,
It seems I forgot to record the rdiff file.
On 4/23/19 4:55 PM, Eugene Kosov wrote:
Hello, Marko, Alexander.
23.04.2019, 15:37, "Marko Mäkelä" :
Bar, thank you for the revision.
I ran all tests and found a regression for ROW_FORMAT=REDUNDANT, in
the test
Hello, Marko, Alexander.
23.04.2019, 15:37, "Marko Mäkelä" :
> Bar, thank you for the revision.
>
> I ran all tests and found a regression for ROW_FORMAT=REDUNDANT, in
> the test innodb.instant_alter_charset,redundant. We should allow any
> extension of VARCHAR maximum length (in bytes) for
>
Bar, thank you for the revision.
I ran all tests and found a regression for ROW_FORMAT=REDUNDANT, in
the test innodb.instant_alter_charset,redundant. We should allow any
extension of VARCHAR maximum length (in bytes) for
ROW_FORMAT=REDUNDANT. The test attempts to enlarge the column from
50*3 to
Hi Marko, Eugene,
Thanks for good suggestions. A new version is attached.
See details inline:
On 4/19/19 2:46 PM, Marko Mäkelä wrote:
Hi Bar,
I see that these bugs were based on wrong assumptions that ASCII or
UCS2 columns would only contain valid ASCII or UTF-16 data. We should
have tested
Hi Bar,
I see that these bugs were based on wrong assumptions that ASCII or
UCS2 columns would only contain valid ASCII or UTF-16 data. We should
have tested these assumptions during the development of MDEV-15564.
Luckily these were found before the GA release of MariaDB 10.4.
Here is just a
Hi Marko and Eugene,
please review a patch fixing:
- MDEV-19284 INSTANT ALTER with ucs2-to-utf16 conversion produces bad data
- MDEV-19285 INSTANT ALTER from ascii_general_ci to latin1_general_ci
produces currupt data
Thanks!
commit 8ac8df9685bb0ee591602e4ca76a45725fa364de
Author: Alexander
9 matches
Mail list logo
