MySQL Bugs: #105895: maxRecordSize required to update in BACKUP_FRAGMENT

Bug #105895	maxRecordSize required to update in BACKUP_FRAGMENT_REQ for LCPs
Submitted:	14 Dec 2021 18:47	Modified:	3 May 2023 21:09
Reporter:	Mikael Ronström	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	8.0.27	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
When an ALTER TABLE adds columns the maximum record size increases.
This size is used by LCPs to allocate buffer space for rows. It is checked that
we don't receive rows larger than this.

However it is currently possible to add columns without changing maxRecordSize.
It is set in GET_TABINFOCONF and in SCAN_FRAGCONF. However there could be
a significant delay between GET_TABINFOCONF and BACKUP_FRAGMENT_REQ
and during this time there is nothing preventing the ALTER TABLE to change the
number of columns.

The solution is to read the maxRecordSize in BACKUP_FRAGMENT_REQ to avoid this
problem.

How to repeat:
testDict -r 2500 TableAddAttrs
To increase chance of getting this problem one can delay sending BACKUP_FRAGMENT_REQ
in this test case.

Suggested fix:
See above

Spellchecked title

Thanks for the report Mikael,

all best
Bogdan

Documented fix as follows in the NDB 8.1.0 changelog:

    When an ALTER TABLE adds columns to an existing table the
    maxRecordSize used by LCPs to allocate buffer space for rows may
    change; this is set in a GET_TABINFOCONF signal and used later
    in BACKUP_FRAGMENT_REQ. If, during the gap between these two
    signals, an ALTER TABLE changed the number of columns, the value
    of maxRecordSize used could be stale, thus be inaccurate, and so
    lead to further issues.

    Now we always update maxRecordSize (from DBTUP) on receipt of a
    BACKUP_FRAGMENT_REQ signal, before allocation of the row buffer.

Closed.

Also fixed in NDB 8.0.35, docs as per previous. No other changes.