Re: Mnesia:add_table_copy causes crashes when no replicas available

Thanks for the bug-report I will take a look at it.

/Dan

On Wed, Dec 10, 2014 at 5:58 PM, Vladislav Titov <[email protected]> wrote:

> Hi
>
> This is on a fully in-RAM mnesia cluster.
>
> When performing mnesia:add_table_copy(tab, node(), ram_copies) when no
> active replicas of tab are available, it replies back correctly with
> {aborted, {system_limit, tab, ...}}.
>
> However, looking at the mnesia_gvar afterwards, the {schema, local_tables}
> key lists the table in it.
>
> This (?) then causes mnesia to shut down when a node that is listed as
> having the table gets started and adopts it as an orphan. In R14 (our
> target release for now):
>
> FATAL ** Sender failed: {error, {no_exists, tab}}
>
> Or in R17:
>
> FATAL ** Cannot load table foo from disc: {not_loaded, storage_unknown}
>
> This then causes mnesia to shutdown.
>
> The R14 case only happens if the node listed as actually holding the table
> starts, and then re-starts. In R17 it seems to happen straight away on
> first startup.
>
> The active_replicas option for the table ends up listing the node() as
> well at some point.
>
> I've attached a repo case.
>
> Any idea how I can work around this? Obviously checking active_replicas
> before a copy would be a good idea, but it wouldn't protect against race
> conditions when nodes are yo-yoing. Would cleaning up the local_tables gvar
> be a good idea if system_limit happens?
>
> thanks,
> vlad
>
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> [email protected]
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>

_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs