[MDEV-15563] Instant failure-free data type conversions - Jira

Details

Type: Task
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Fix Version/s: 10.4.3
Component/s: Storage Engine - InnoDB
Labels:
- instant
- online-ddl

Description

The original InnoDB record format (retroactively named ROW_FORMAT=REDUNDANT in MySQL 5.0.3) basically treats every column as variable-length and possibly NULL. That is why we can freely change those columns, by changing the metadata only.

MariaDB 10.2 supports VARCHAR column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For ROW_FORMAT=REDUNDANT we should support this unconditionally.

Likewise, for ROW_FORMAT=REDUNDANT we can support the extension of any CHAR column, or converting VARCHAR to a CHAR that is at least as wide.

We can also support converting INT to BIGINT and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as INT UNSIGNED to BIGINT), but this would require a change to the 'metadata row' format to indicate that the column originally was in unsigned format.

To support instant conversion of CHAR to VARCHAR, we should store a flag in the ~~MDEV-15562~~ metadata record to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt and this is, obviously, not and INSTANT operation:

CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB;

INSERT INTO t VALUES('a ');

SELECT HEX(a) FROM t;

ALTER TABLE t CHANGE a a VARCHAR(2);

SELECT HEX(a) FROM t;

DROP TABLE t;

The above example would read 'a' from the column and not 'a '.
Similarly, for changing INT UNSIGNED to BIGINT we should add a flag that the shorter column was unsigned.

TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column (CHAR, BINARY) is changed?

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

UNSIGNED-bigger-signed.patch
14 kB
2019-02-13 16:50

Issue Links

blocks

MDEV-11424 Instant ALTER TABLE of failure-free record format changes

Closed

MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes

Closed

causes

MDEV-18124 PK on inplace-enlarged type fails

Closed

MDEV-18596 ASAN unknown-crash in row_mysql_store_col_in_innobase_format upon MODIFY / ADD column

Closed

MDEV-18598 Assertion `is_string == dtype_is_string_type(mtype)' failed in innobase_rename_or_enlarge_columns_cache upon MODIFY column

Closed

MDEV-18623 Assertion `ha_alter_info->key_count + .... in prepare_inplace_alter_table_dict

Closed

MDEV-18627 Wrong result after instant size change of integer

Closed

MDEV-18719 Assertion `!((c.prtype ^ o->prtype) & ~(256U | (16384U|32768U)))' failed in dict_table_t::instant_column

Closed

MDEV-21539 Assertion `!((new_col->prtype ^ col->prtype) & ~256U)' failed in row_log_table_apply_convert_mrec

Closed

MDEV-22465 DROP COLUMN, DROP INDEX is wrongly claimed to be ALGORITHM=INSTANT

Closed

MDEV-25236 Online log apply fails for redundant row format tables

Closed

relates to

MDEV-16849 Extending indexed VARCHAR column should be instantaneous

Closed

MDEV-18035 InnoDB: Failing assertion: field->col->mtype == type in storage/innobase/row/row0sel.cc line 2549

Closed

MDEV-18649 Assertion `supremum[7] == index.n_core_null_bytes' failed in btr_set_instant

Closed

MDEV-18780 Assertion `col->prtype == prtype' failed in innobase_rename_or_enlarge_column_try upon CHANGE COLUMN

Confirmed

MDEV-22771 Assertion `fields[i].same(instant.fields[i])' failed in dict_index_t::instant_add_field

Closed

MDEV-28060 Online DDL fails while checking for instant alter condition

Closed

MDEV-33069 Instant Modify Column

Open

(6 causes, 7 relates to)

Activity

Ascending order - Click to sort in descending order

Marko Mäkelä created issue - 2018-03-14 13:34

Marko Mäkelä made changes - 2018-03-14 13:34

Field	Original Value	New Value
Link		This issue blocks ~~MDEV-11424~~ [ ~~MDEV-11424~~ ]

Marko Mäkelä made changes - 2018-03-14 13:52

Status

Open [ 1 ]

Confirmed [ 10101 ]

Ralf Gebhardt made changes - 2018-04-26 17:31

NRE Approved

Yes [ 10304 ]

Marko Mäkelä made changes - 2018-05-31 08:41

Summary

Instant NOT NULL removal and CHAR or VARCHAR extension for ROW_FORMAT=REDUNDANT

Instant NOT NULL removal and conversion to a wider type for ROW_FORMAT=REDUNDANT

Marko Mäkelä made changes - 2018-05-31 08:48

Description

The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only.

For {{ROW_FORMAT=REDUNDANT}}, we should allow an instantaneous change of a column from {{NOT NULL}} to {{NULL}}.

MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally.

Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column.

Unfortunately, we cannot support instant conversion of {{CHAR}} to {{VARCHAR}}, because the instant conversion would not trim trailing space, unlike the full conversion:
{code:sql}
CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB;
INSERT INTO t VALUES('a ');
SELECT HEX(a) FROM t;
ALTER TABLE t CHANGE a a VARCHAR(2);
SELECT HEX(a) FROM t;
DROP TABLE t;
{code}
The above example would read {{'a'}} from the column and not {{'a '}}.

TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?

The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only.

For {{ROW_FORMAT=REDUNDANT}}, we should allow an instantaneous change of a column from {{NOT NULL}} to {{NULL}}.

MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally.

Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column, or converting {{VARCHAR}} to a {{CHAR}} that is at least as wide.

We can also support converting {{INT}} to {{BIGINT}} and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as {{INT UNSIGNED}} to {{BIGINT}}), but this would require a change to the 'default row' format to indicate that the column originally was in unsigned format.

To support instant conversion of {{CHAR}} to {{VARCHAR}}, we should store a flag in the 'default row' to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt:
{code:sql}
CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB;
INSERT INTO t VALUES('a ');
SELECT HEX(a) FROM t;
ALTER TABLE t CHANGE a a VARCHAR(2);
SELECT HEX(a) FROM t;
DROP TABLE t;
{code}
The above example would read {{'a'}} from the column and not {{'a '}}.

TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?

Julien Fritsch made changes - 2018-07-05 14:24

Epic Link

PT-80 [ 68561 ]

Ralf Gebhardt made changes - 2018-08-21 16:38

Priority

Major [ 3 ]

Critical [ 2 ]

Ralf Gebhardt made changes - 2018-08-23 13:07

Rank

Ranked higher

Ralf Gebhardt made changes - 2018-09-13 10:52

Target end

12/Feb/19 [ 2019-02-12 ]

Rasmus Johansson (Inactive) made changes - 2018-09-17 07:53

Assignee

Thirunarayanan Balathandayuthapani [ thiru ]

Eugene Kosov [ kevg ]

Marko Mäkelä made changes - 2018-09-20 14:23

Link

This issue relates to ~~MDEV-16849~~ [ ~~MDEV-16849~~ ]

Eugene Kosov (Inactive) made changes - 2018-10-16 12:02

Status

Confirmed [ 10101 ]

In Progress [ 3 ]

Marko Mäkelä made changes - 2018-10-22 14:35

Link

This issue blocks MDEV-17520 [ MDEV-17520 ]

Eugene Kosov (Inactive) made changes - 2018-10-24 11:44

Assignee	Eugene Kosov [ kevg ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Marko Mäkelä made changes - 2018-10-31 12:02

Assignee	Marko Mäkelä [ marko ]	Eugene Kosov [ kevg ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Eugene Kosov (Inactive) made changes - 2018-11-01 11:19

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Eugene Kosov (Inactive) made changes - 2018-11-01 11:19

Assignee	Eugene Kosov [ kevg ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Marko Mäkelä made changes - 2018-11-05 08:53

Assignee	Marko Mäkelä [ marko ]	Eugene Kosov [ kevg ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Aleksey Midenkov made changes - 2018-11-05 09:53

Assignee

Eugene Kosov [ kevg ]

Aleksey Midenok [ midenok ]

Aleksey Midenkov made changes - 2018-11-05 09:53

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Eugene Kosov (Inactive) made changes - 2018-11-09 08:25

Description

The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only.

For {{ROW_FORMAT=REDUNDANT}}, we should allow an instantaneous change of a column from {{NOT NULL}} to {{NULL}}.

MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally.

Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column, or converting {{VARCHAR}} to a {{CHAR}} that is at least as wide.

We can also support converting {{INT}} to {{BIGINT}} and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as {{INT UNSIGNED}} to {{BIGINT}}), but this would require a change to the 'default row' format to indicate that the column originally was in unsigned format.

To support instant conversion of {{CHAR}} to {{VARCHAR}}, we should store a flag in the 'default row' to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt:
{code:sql}
CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB;
INSERT INTO t VALUES('a ');
SELECT HEX(a) FROM t;
ALTER TABLE t CHANGE a a VARCHAR(2);
SELECT HEX(a) FROM t;
DROP TABLE t;
{code}
The above example would read {{'a'}} from the column and not {{'a '}}.

TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?

The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only.

For {{ROW_FORMAT=REDUNDANT}}, we should allow an instantaneous change of a column from {{NOT NULL}} to {{NULL}}.

MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally.

Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column, or converting {{VARCHAR}} to a {{CHAR}} that is at least as wide.

We can also support converting {{INT}} to {{BIGINT}} and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as {{INT UNSIGNED}} to {{BIGINT}}), but this would require a change to the 'metadata row' format to indicate that the column originally was in unsigned format.

To support instant conversion of {{CHAR}} to {{VARCHAR}}, we should store a flag in the 'metadata row' to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt:
{code:sql}
CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB;
INSERT INTO t VALUES('a ');
SELECT HEX(a) FROM t;
ALTER TABLE t CHANGE a a VARCHAR(2);
SELECT HEX(a) FROM t;
DROP TABLE t;
{code}
The above example would read {{'a'}} from the column and not {{'a '}}.

TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?

Eugene Kosov (Inactive) made changes - 2018-11-09 08:28

Description

The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only.

For {{ROW_FORMAT=REDUNDANT}}, we should allow an instantaneous change of a column from {{NOT NULL}} to {{NULL}}.

MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally.

Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column, or converting {{VARCHAR}} to a {{CHAR}} that is at least as wide.

We can also support converting {{INT}} to {{BIGINT}} and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as {{INT UNSIGNED}} to {{BIGINT}}), but this would require a change to the 'metadata row' format to indicate that the column originally was in unsigned format.

To support instant conversion of {{CHAR}} to {{VARCHAR}}, we should store a flag in the 'metadata row' to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt:
{code:sql}
CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB;
INSERT INTO t VALUES('a ');
SELECT HEX(a) FROM t;
ALTER TABLE t CHANGE a a VARCHAR(2);
SELECT HEX(a) FROM t;
DROP TABLE t;
{code}
The above example would read {{'a'}} from the column and not {{'a '}}.

TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?

The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only.

For {{ROW_FORMAT=REDUNDANT}}, we should allow an instantaneous change of a column from {{NOT NULL}} to {{NULL}}.

MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally.

Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column, or converting {{VARCHAR}} to a {{CHAR}} that is at least as wide.

We can also support converting {{INT}} to {{BIGINT}} and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as {{INT UNSIGNED}} to {{BIGINT}}), but this would require a change to the 'metadata row' format to indicate that the column originally was in unsigned format.

To support instant conversion of {{CHAR}} to {{VARCHAR}}, we should store a flag in the 'metadata row' to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt and this is, obviously, not and {{INSTANT}} operation:
{code:sql}
CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB;
INSERT INTO t VALUES('a ');
SELECT HEX(a) FROM t;
ALTER TABLE t CHANGE a a VARCHAR(2);
SELECT HEX(a) FROM t;
DROP TABLE t;
{code}
The above example would read {{'a'}} from the column and not {{'a '}}.

TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?

Marko Mäkelä made changes - 2018-11-09 11:43

Link

This issue is blocked by MDEV-17520 [ MDEV-17520 ]

Marko Mäkelä made changes - 2018-11-09 12:03

Link

This issue blocks MDEV-17520 [ MDEV-17520 ]

Marko Mäkelä made changes - 2018-11-09 12:08

Description	The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only. For {{ROW_FORMAT=REDUNDANT}}, we should allow an instantaneous change of a column from {{NOT NULL}} to {{NULL}}. MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally. Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column, or converting {{VARCHAR}} to a {{CHAR}} that is at least as wide. We can also support converting {{INT}} to {{BIGINT}} and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as {{INT UNSIGNED}} to {{BIGINT}}), but this would require a change to the 'metadata row' format to indicate that the column originally was in unsigned format. To support instant conversion of {{CHAR}} to {{VARCHAR}}, we should store a flag in the 'metadata row' to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt and this is, obviously, not and {{INSTANT}} operation: {code:sql} CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB; INSERT INTO t VALUES('a '); SELECT HEX(a) FROM t; ALTER TABLE t CHANGE a a VARCHAR(2); SELECT HEX(a) FROM t; DROP TABLE t; {code} The above example would read {{'a'}} from the column and not {{'a '}}. TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?	The original InnoDB record format (retroactively named {{ROW_FORMAT=REDUNDANT}} in MySQL 5.0.3) basically treats every column as variable-length and possibly {{NULL}}. That is why we can freely change those columns, by changing the metadata only. MariaDB 10.2 supports {{VARCHAR}} column extension, but only if the maximum length does not change from less than 256 to at least 256 bytes. For {{ROW_FORMAT=REDUNDANT}} we should support this unconditionally. Likewise, for {{ROW_FORMAT=REDUNDANT}} we can support the extension of any {{CHAR}} column, or converting {{VARCHAR}} to a {{CHAR}} that is at least as wide. We can also support converting {{INT}} to {{BIGINT}} and similar. Maybe also conversion from an unsigned integer to a signed wider integer (such as {{INT UNSIGNED}} to {{BIGINT}}), but this would require a change to the 'metadata row' format to indicate that the column originally was in unsigned format. To support instant conversion of {{CHAR}} to {{VARCHAR}}, we should store a flag in the ~~MDEV-15562~~ metadata record to indicate that trailing space should be trimmed, just like it would if the table was rebuilt. In this case, any secondary indexes on the column would have to be rebuilt and this is, obviously, not and {{INSTANT}} operation: {code:sql} CREATE TABLE t(a CHAR(2)) ENGINE=InnoDB; INSERT INTO t VALUES('a '); SELECT HEX(a) FROM t; ALTER TABLE t CHANGE a a VARCHAR(2); SELECT HEX(a) FROM t; DROP TABLE t; {code} The above example would read {{'a'}} from the column and not {{'a '}}. Similarly, for changing {{INT UNSIGNED}} to {{BIGINT}} we should add a flag that the shorter column was unsigned. TO BE DETERMINED: On secondary indexes of full columns (not column prefixes), do we have to rebuild the index when the length of a fixed-length column ({{CHAR}}, {{BINARY}}) is changed?
Summary	Instant NOT NULL removal and conversion to a wider type for ROW_FORMAT=REDUNDANT	Instant failure-free data type conversions

Aleksey Midenkov made changes - 2018-12-03 10:57

Assignee	Aleksey Midenok [ midenok ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Marko Mäkelä made changes - 2018-12-21 13:37

Link

This issue relates to ~~MDEV-18035~~ [ ~~MDEV-18035~~ ]

Aleksey Midenkov made changes - 2019-01-09 10:25

Link

This issue causes ~~MDEV-18124~~ [ ~~MDEV-18124~~ ]

Marko Mäkelä made changes - 2019-01-16 07:51

Link

This issue blocks ~~MDEV-15564~~ [ ~~MDEV-15564~~ ]

Marko Mäkelä made changes - 2019-01-16 07:51

Link

This issue is blocked by MDEV-17520 [ MDEV-17520 ]

Eugene Kosov (Inactive) made changes - 2019-01-21 17:22

Link

This issue is blocked by MDEV-18326 [ MDEV-18326 ]

Marko Mäkelä made changes - 2019-02-13 16:50

Attachment

UNSIGNED-bigger-signed.patch [ 47290 ]

Marko Mäkelä made changes - 2019-02-13 16:54

issue.field.resolutiondate

2019-02-13 16:54:37.0

2019-02-13 16:54:37.819

Marko Mäkelä made changes - 2019-02-13 16:54

Fix Version/s		10.4.3 [ 23230 ]
Fix Version/s	10.4 [ 22408 ]
Resolution		Fixed [ 1 ]
Status	In Review [ 10002 ]	Closed [ 6 ]

Marko Mäkelä made changes - 2019-02-16 21:02

Link

This issue causes ~~MDEV-18598~~ [ ~~MDEV-18598~~ ]

Marko Mäkelä made changes - 2019-02-18 08:01

Link

This issue causes ~~MDEV-18596~~ [ ~~MDEV-18596~~ ]

Marko Mäkelä made changes - 2019-02-18 13:23

Link

This issue causes ~~MDEV-18627~~ [ ~~MDEV-18627~~ ]

Marko Mäkelä made changes - 2019-02-20 08:49

Link

This issue relates to ~~MDEV-18649~~ [ ~~MDEV-18649~~ ]

Marko Mäkelä made changes - 2019-02-20 09:58

Link

This issue is blocked by MDEV-18326 [ MDEV-18326 ]

Marko Mäkelä made changes - 2019-02-25 02:10

Link

This issue causes ~~MDEV-18719~~ [ ~~MDEV-18719~~ ]

Marko Mäkelä made changes - 2019-03-04 10:10

Link

This issue relates to MDEV-18780 [ MDEV-18780 ]

Marko Mäkelä made changes - 2019-03-20 14:46

NRE Projects

NRE-310017 RM_104_NRE

NRE-310017 RM_104_NRE RM_102ES_CANDIDATE RM_103ES_CANDIDATE

Marko Mäkelä made changes - 2019-04-01 14:16

Link

This issue causes ~~MDEV-18623~~ [ ~~MDEV-18623~~ ]

Marko Mäkelä made changes - 2020-01-21 16:28

Link

This issue causes ~~MDEV-21539~~ [ ~~MDEV-21539~~ ]

Marko Mäkelä made changes - 2020-05-05 09:23

Link

This issue causes ~~MDEV-22465~~ [ ~~MDEV-22465~~ ]

Marko Mäkelä made changes - 2020-07-20 08:55

Link

This issue relates to ~~MDEV-22771~~ [ ~~MDEV-22771~~ ]

Marko Mäkelä made changes - 2021-07-02 13:30

Link

This issue causes ~~MDEV-25236~~ [ ~~MDEV-25236~~ ]

Marko Mäkelä made changes - 2021-07-23 10:48

Link

This issue causes ~~MDEV-26224~~ [ ~~MDEV-26224~~ ]

Marko Mäkelä made changes - 2021-07-23 12:33

Link

This issue causes ~~MDEV-26224~~ [ ~~MDEV-26224~~ ]

Sergei Golubchik made changes - 2021-12-06 21:23

Workflow

MariaDB v3 [ 86022 ]

MariaDB v4 [ 133494 ]

Marko Mäkelä made changes - 2022-03-14 14:23

Link

This issue relates to ~~MDEV-28060~~ [ ~~MDEV-28060~~ ]

Marko Mäkelä made changes - 2023-12-19 13:22

Link

This issue relates to MDEV-33069 [ MDEV-33069 ]

People

Assignee:: Marko Mäkelä

Reporter:: Marko Mäkelä

Votes:: 1 Vote for this issue

Watchers:: 6 Start watching this issue

Dates

Created:: 2018-03-14 13:34

Updated:: 2023-12-19 13:22

Resolved:: 2019-02-13 16:54

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration