You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: I86695f34e88e70bd2fded2479fa90a75437eba28
0 commit comments