Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

PS-9222 Include reordered fields when calculating mlog buffer size #5321

Merged
merged 2 commits into from
Jun 28, 2024
Merged

PS-9222 Include reordered fields when calculating mlog buffer size #5321

merged 2 commits into from
Jun 28, 2024

Commits on Jun 28, 2024

  1. PS-9222 ALTER TABLE ALGORITHM=INSTANT FIX #1 

    https://perconadev.atlassian.net/browse/PS-9222

Problem
=======
When writing to the redo log, an issue of column order change not
being recorded with INSTANT DDL was fixed by creating an array
with size equal to the number of fields in the index which kept
track of whether the original position of the field was changed
or not. Later, that array would be used to make a decision on
logging the field.
But, this solution didn't take into account the fact that
there could be column prefixes because of the primary key. This
resulted in inaccurate entries being filled in the
fields_with_changed_order[] array.

Solution
========
It is fixed by using the method, get_col_phy_pos() which takes
into account the existence of column prefix instead of get_phy_pos()
while generating fields_with_changed_order[] array.
    @VarunNagaraju
    VarunNagaraju committed Jun 28, 2024
    Configuration menu
    Copy the full SHA
    d537fd3 View commit details
    Browse the repository at this point in the history

  2. PS-9222 ALTER TABLE ALGORITHM=INSTANT FIX #2 

    https://perconadev.atlassian.net/browse/PS-9222

Problem
=======
When writing to the redo log, an issue of column order change not
being recorded with INSTANT DDL was fixed by checking if the fields
are also reordered, then adding the columns into the list.
However when calculating the size of the buffer this fix doesn't take
account the extra fields that may be logged, and causing the assertion
on the buffer size failed eventually.

Solution
========
To calculate the buffer size correctly, we move the logic of finding
reordered fiedls before buffer size calculation, then count the number
of fields with the same logic when deciding if a field needs to be logged.
    @VarunNagaraju
    VarunNagaraju committed Jun 28, 2024
    Configuration menu
    Copy the full SHA
    39e9957 View commit details
    Browse the repository at this point in the history