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.

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

Michal/mnesia/add_tests_for_compare_storage_type #9444

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Mikaka27
Copy link
Contributor

Those tests are related to #9311.
When investigating problem during schema merge it was found that when some nodes in the cluster are down, it's still possible to call mnesia:change_table_copy_type/3 for 2 special cases:

  • ram_copies -> disc_copies
  • disc_copies -> disc_only_copies

The cause of this is that mnesia_schema:compare_storage_types/3 does not consider the two (mentioned above) conversions as incompatible, this can be seen here:

compare_storage_type(_Retry, ram_copies, disc_copies) ->
{diff, disc_copies};
compare_storage_type(_Retry, disc_copies, disc_only_copies) ->
{diff, disc_only_copies};

The cause is in mnesia_schema:make_change_table_copy_type/3, one can see that only when storage type is incompatible, it calls ensure_active(Cs)

case compare_storage_type(false, FromS, ToSExp) of
{same, _} ->
mnesia:abort({already_exists, Tab, Node, ToSExp});
{diff, _} ->
ignore;
incompatible ->
ensure_active(Cs)
end,

In addition to that:

compare_storage_type(_Retry, ram_copies, disc_copies) ->
    {diff, disc_copies};

is used for merging a schema after it's removal (when node rejoins the cluster), this can be seen in mnesia_config_test:dynamic_basic/1 when doing following operations:

?match([], mnesia_test_lib:kill_mnesia([N2])),
?match(ok, mnesia:delete_schema([N2])),
?match(ok, mnesia:dirty_write({tab1, 1, 1})),
?match(ok, mnesia:dirty_write({tab2, 1, 1})),
?match(ok, rpc:call(N2, mnesia, start, [[{extra_db_nodes, [N1]}, {schema, ?BACKEND}]])),

The cause of that is when we remove node's schema it restarts with ram_copies schema, and later has to join a cluster and convert it's schema to disc_copies.
This is mentioned in the documentation: https://www.erlang.org/doc/apps/mnesia/mnesia.html#module-configuration-parameters

opt_disc - Optional disc. The schema can reside on disc or in RAM. If the schema is found on disc, Mnesia starts as a disc-based node and the storage type of the schema table is disc_copies. If no schema is found on disc, Mnesia starts as a disc-less node and the storage type of the schema table is ram_copies. Default value for the application parameter is opt_disc.

but

compare_storage_type(_Retry, disc_copies, disc_only_copies) ->
    {diff, disc_only_copies};

is not covered by any tests, so add tests for both of those cases.

@Mikaka27 Mikaka27 added the team:PS Assigned to OTP team PS label Feb 14, 2025
@Mikaka27 Mikaka27 requested a review from dgud February 14, 2025 17:25
Copy link
Contributor

github-actions bot commented Feb 14, 2025

CT Test Results

  2 files   59 suites   19m 47s ⏱️
683 tests 535 ✅ 148 💤 0 ❌
737 runs  574 ✅ 163 💤 0 ❌

Results for commit 54cb7c6.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

// Erlang/OTP Github Action Bot

@Mikaka27 Mikaka27 changed the title Add tests for compare_storage_type Michal/mnesia/add_tests_for_compare_storage_type Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team:PS Assigned to OTP team PS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant