Fragment not locked - again
Dan Gudmundsson
dangud@REDACTED
Mon Sep 20 13:24:35 CEST 2021
I only looked briefly the last time you pointed it out, and it does look
strange,
though I have not had time to dig deeper into it.
If you use fragmented tables to be able store larger tables on disk_only,
maybe you should look at https://github.com/klarna/mnesia_eleveldb or some
other backend. I have not used it myself but there are people on this list
using it.
/Dan
On Sun, Sep 19, 2021 at 5:09 PM Wojtek Surowka <wojteksurowka@REDACTED> wrote:
> I have sent the same question some time ago but could not get any solution.
> Maybe this time I will be luckier, especially that I made new observations:
>
> I have a fragmented table in Mnesia of type disc_only_copies. There is a
> 2GB
> size limit for tables of that type, and this table grows continuously with
> new data. Because of that I have the code which periodically (weekly)
> checks
> sizes of fragments and adds new fragments (usually just one) if necessary.
> The call I use to add a new fragment is:
>
> mnesia:change_table_frag(name, {add_frag, [node()]}).
>
> And it works, till it does not. Right now my table is in a state when any
> call to add a new fragment returns
>
> {aborted,{"add_frag: Fragment not locked",12}}
>
> All earlier change_table_frag calls were successful, but it looks like at
> certain moment something bad happened and since then adding a new fragment
> to the table is not possible. Every time it returns the error message. Is
> it
> a bug in Mnesia? Is there anything I could do to continue adding new
> fragments?
>
> Thanks,
> Wojtek
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210920/c26e75fd/attachment.htm>
More information about the erlang-questions
mailing list