[MDEV-33141] Straight out the write-marking requirement rules Created: 2023-12-29  Updated: 2024-01-03

Status: Open
Project: MariaDB Server
Component/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Nikita Malyavin Assignee: Nikita Malyavin
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-33135 Refactor Field::reset() Open

 Description   

Currently we DBUG_ASSERT(marked_for_write_or_computed()) for every Field::store_value() however we use these stores even for reading purposes. To override this, the assertion has evolved from write-marking assertion to a complicated set of rules, which in particular includes

  • checking for computed - however, we loose a big plane of assertions when writing the computed stored columns
  • checking for table->record[0], which is another thing preventing from using an arbitrary record for storing and invoking ha_* functions

For now the proposal is to make two sets of store_value functions: one for read and one for write. Let's see if current use cases may fit into it, and if they do, then implement it.



 Comments   
Comment by Sergei Golubchik [ 2024-01-03 ]

I think the underlying problem here is that marked_for_write assert is incorrectly placed.
It doesn't actually matter what fields are updated in the row image, this doesn't need write_set bitmap, so the assert should not check it.
write_set bitmap shows what fields will be stored in the table after this row image is sent to the engine (in write_row() or update_row() method.

There is really no good way of checking whether write_set is correct. Current assert is store() gets too many false positives (that's why it evolved into a very complex expression). We could put at assert in write_row(), verifying that all fields from the write_set were given values and all other fields weren't — but, again, I expect false positives for cases when the field got a value, but we don't expect it to be stored.

Practically, I don't remember when these asserts fired correctly, indicating a problem to be fixed. So may be a best way forward is simply to remove them altogether.

Generated at Thu Feb 08 10:36:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.