Commit 7b81cc3
committed
Bug#37292404 Update instant dropped extern blob
Thanks to mengchu shi (Alibaba) for the contribution. Background: Row update is done: 1. In-place, if the changes fit within the row 2. Optimistically, if the changes fit within the page and page re-organization is not required 3. Pessimistically otherwise: the old row is deleted and updated row is inserted The following steps are followed during pessimistic update: 1. Prepare in-memory copy (dtuple_t) from the physical record (rec_t) 2. Apply changes to the tuple as described by the update vector 3. Check if field(s) of the tuple must be stored externally 4. If yes, then modify update vector and tuple to indicate it; and create a big record (big_rec_t) 5. Perform undo logging 6. Delete the old physical record 7. Create the physical record (rec_t) back from the updated tuple 8. Insert the updated record Description: When performing undo logging, we log all the fields being modified by the update vector into the undo log. We must not encounter any field which is dropped instantly when logging to the undo log. That is, the update vector must not contain any field which is dropped instantly when we start performing undo logging. When a column is dropped with ALGORITHM=INSTANT, the existing rows are not touched. Thus, an in-memory tuple built from the such existing rows will contain the field(s) which are dropped instantly. Issue: Consider the following scenario: 1. Table is created with a blob column say c1 2. Row is inserted such that c1 is stored externally 3. ALTER TABLE .. DROP COLUMN c1, ALGORITHM=INSTANT; 4. Row is updated and the update is done pessimistically Observe the field c1 along the steps of the pessimistic update: 1. The in-memory copy will contain the dropped field c1 as the column was dropped with ALGORITHM=INSTANT 2. The changes to the tuple will propagate the dropped field as is to the updated tuple 3. The field c1 must be stored externally 4. The field c1 is stored externally and the update vector now includes c1 5. We reach an unexpected state here, causing the server to halt. The field c1 is being undo logged as it is part of the update vector. But the field c1 is already dropped instantly. This violates the prerequisite of undo logging (see Description). Fix: When applying the update on the tuple, ensure that any field which is dropped instantly is removed from the tuple. This ensures that dropped fields are not propagated and are not considered in later stages of the update. Note: When the update is performed pessimistically, the row is brought to the latest row version. This is done when inserting the updated row. Change-Id: I86695f34e88e70bd2fded2479fa90a75437eba281 parent 1ada17e commit 7b81cc3
1 file changed
+19
-22
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1119 | 1119 | | |
1120 | 1120 | | |
1121 | 1121 | | |
1122 | | - | |
1123 | | - | |
1124 | | - | |
1125 | | - | |
1126 | | - | |
1127 | 1122 | | |
1128 | 1123 | | |
1129 | 1124 | | |
1130 | 1125 | | |
1131 | 1126 | | |
1132 | | - | |
1133 | | - | |
1134 | | - | |
1135 | | - | |
1136 | | - | |
| 1127 | + | |
| 1128 | + | |
| 1129 | + | |
| 1130 | + | |
| 1131 | + | |
1137 | 1132 | | |
1138 | | - | |
1139 | | - | |
1140 | | - | |
1141 | | - | |
| 1133 | + | |
| 1134 | + | |
1142 | 1135 | | |
1143 | | - | |
1144 | | - | |
1145 | | - | |
1146 | | - | |
| 1136 | + | |
| 1137 | + | |
| 1138 | + | |
| 1139 | + | |
| 1140 | + | |
1147 | 1141 | | |
1148 | | - | |
| 1142 | + | |
| 1143 | + | |
| 1144 | + | |
1149 | 1145 | | |
1150 | | - | |
| 1146 | + | |
1151 | 1147 | | |
1152 | 1148 | | |
1153 | | - | |
| 1149 | + | |
1154 | 1150 | | |
1155 | | - | |
| 1151 | + | |
1156 | 1152 | | |
1157 | 1153 | | |
1158 | 1154 | | |
1159 | 1155 | | |
| 1156 | + | |
1160 | 1157 | | |
1161 | 1158 | | |
1162 | 1159 | | |
| |||
0 commit comments