Fragment not locked
Wojtek Surowka
wojteksurowka@REDACTED
Mon Jul 12 14:29:10 CEST 2021
> Following the documentation, are you trying to reproduce example for
> {hash_state, Term}? The line "mnesia:change_table_frag(prim_dict, {add_frag, [node()]})." can be found only there.
> Or you've somehow changed those examples for your own needs? If so please provide a full list of your steps.
I do not try to reproduce this example. I created table using {atomic, ok} = mnesia:create_table(tablename, [{attributes, record_info(fields, tablename)}, {disc_only_copies, [node()]}])
I write to this table with
ok = mnesia:activity(sync_transaction, fun () -> mnesia:write(RecordToWrite) end, [], mnesia_frag) this is called within mnesia:transaction because also other tables are accessed. A write like this happens several times every minute, and nearly always record is replacing an already existing one with the same key.
I read from this table with
mnesia:activity(sync_dirty, fun () -> mnesia:read(tablename, RecordSpec) end, [], mnesia_frag) Reading happens occasionally, when end users activity triggers it.
When I detect that fragment tables are bigger than some threshold, I add a new fragment with mnesia:change_table_frag(tablename, {add_frag, [node()]}) I used [node()] as the second element of add_frag tuple since documentation says it is either the list of nodes or a frag_dist result. I use one node, so [node()] seemed appropriate.
It was all working for some time, but since some time it stopped - to be precise, reads and writes work correctly, but adding a new fragment fails every time. Right now the table has 16 fragments, total of 1.7M records, and the biggest fragment is now 1.6GB on disk.
I considered copying all data, recreating the table with more fragments and copying back, but I hope there is something I can do to avoid this procedure.
(Sorry for posting this by mistake to you instead of the mailing list)
Thanks,
Wojtek
More information about the erlang-questions
mailing list