Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4.12
-
None
-
10.4.12-MariaDB-1:10.4.12+maria~bionic
docker image from docker hub
Description
Reproduce
create table t1 ( |
x int unique, |
y int without system versioning |
) with system versioning; |
|
|
insert into t1 (x, y) values ('1', '1'); |
insert into t1 (x, y) values ('1', '2') |
on duplicate key update y = 3; |
|
|
select *, row_start, row_end from t1 for system_time all; |
|
|
drop table t1; |
Result
select *, row_start, row_end from t1 for system_time all; |
x y row_start row_end
|
1 3 2023-07-19 12:38:44.171889 2038-01-19 06:14:07.999999
|
1 1 2023-07-19 12:38:44.171889 2023-07-19 12:38:44.172925
|
Expected
No history rows inserted.
select *, row_start, row_end from t1 for system_time all; |
x y row_start row_end
|
1 3 2023-07-19 12:38:44.171889 2038-01-19 06:14:07.999999
|
Notes
When enable versioning (timestamp) for whole table except one column, using upsert (insert ... on duplicate update) to update the unversioning column, will still create new version records.
How to reproduce: https://hackmd.io/WNz_xg9pRYiQrL69QkufrQ
A workaround is to use txrid (transaction id) based versioning, but it doesn't support partitions to separate current and historic data, still. MDEV-15951
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
When enable versioning (timestamp) for whole table except one column, using upsert (insert ... on duplicate update) to update the unversioning column, will still create new version records.
How to reproduce: https://hackmd.io/WNz_xg9pRYiQrL69QkufrQ A workaround is to use txrid (transaction id) based versioning, but it doesn't support partitions to separate current and historic data, still. https://jira.mariadb.org/browse/MDEV-15951 |
When enable versioning (timestamp) for whole table except one column, using upsert (insert ... on duplicate update) to update the unversioning column, will still create new version records.
How to reproduce: https://hackmd.io/WNz_xg9pRYiQrL69QkufrQ A workaround is to use txrid (transaction id) based versioning, but it doesn't support partitions to separate current and historic data, still. |
| Description |
When enable versioning (timestamp) for whole table except one column, using upsert (insert ... on duplicate update) to update the unversioning column, will still create new version records.
How to reproduce: https://hackmd.io/WNz_xg9pRYiQrL69QkufrQ A workaround is to use txrid (transaction id) based versioning, but it doesn't support partitions to separate current and historic data, still. |
When enable versioning (timestamp) for whole table except one column, using upsert (insert ... on duplicate update) to update the unversioning column, will still create new version records.
How to reproduce: https://hackmd.io/WNz_xg9pRYiQrL69QkufrQ A workaround is to use txrid (transaction id) based versioning, but it doesn't support partitions to separate current and historic data, still. |
| Link |
This issue relates to |
| Fix Version/s | 10.4 [ 22408 ] | |
| Assignee | Aleksey Midenkov [ midenok ] |
| Workflow | MariaDB v3 [ 110890 ] | MariaDB v4 [ 142072 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Description |
When enable versioning (timestamp) for whole table except one column, using upsert (insert ... on duplicate update) to update the unversioning column, will still create new version records.
How to reproduce: https://hackmd.io/WNz_xg9pRYiQrL69QkufrQ A workaround is to use txrid (transaction id) based versioning, but it doesn't support partitions to separate current and historic data, still. |
h3. Reproduce
{code:sql} create table t1 ( x int unique, y int without system versioning ) with system versioning; insert into t1 (x, y) values ('1', '1'); insert into t1 (x, y) values ('1', '2') on duplicate key update y = 3; select *, row_start, row_end from t1 for system_time all; drop table t1; {code} h3. Result {code:sql} select *, row_start, row_end from t1 for system_time all; x y row_start row_end 1 3 2023-07-19 12:38:44.171889 2038-01-19 06:14:07.999999 1 1 2023-07-19 12:38:44.171889 2023-07-19 12:38:44.172925 {code} h3. Expected No history rows inserted. {code:sql} select *, row_start, row_end from t1 for system_time all; x y row_start row_end 1 3 2023-07-19 12:38:44.171889 2038-01-19 06:14:07.999999 {code} h3. Notes When enable versioning (timestamp) for whole table except one column, using upsert (insert ... on duplicate update) to update the unversioning column, will still create new version records. How to reproduce: https://hackmd.io/WNz_xg9pRYiQrL69QkufrQ A workaround is to use txrid (transaction id) based versioning, but it doesn't support partitions to separate current and historic data, still. |
| Summary | upsert to non-versioning column in versioned table should not, but still, created new record. | ODKU of non-versioning column inserts history row |
| Link |
This issue relates to |
| Assignee | Aleksey Midenkov [ midenok ] | Nikita Malyavin [ nikitamalyavin ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Assignee | Nikita Malyavin [ nikitamalyavin ] | Aleksey Midenkov [ midenok ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| Fix Version/s | 10.4.31 [ 29010 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Fix Version/s | 10.11 [ 27614 ] | |
| Fix Version/s | 10.10.6 [ 29017 ] | |
| Fix Version/s | 10.9.8 [ 29015 ] | |
| Fix Version/s | 10.6.15 [ 29013 ] | |
| Fix Version/s | 10.5.22 [ 29011 ] |
| Fix Version/s | 11.0.3 [ 28920 ] | |
| Fix Version/s | 10.11.5 [ 29019 ] |