<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi<div><br></div><div>This is on a fully in-RAM mnesia cluster.</div><div><br></div><div>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, ...}}.</div><div><br></div><div>However, looking at the mnesia_gvar afterwards, the {schema, local_tables} key lists the table in it.</div><div><br></div><div>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):</div><div><br></div><div>FATAL ** Sender failed: {error, {no_exists, tab}}<br></div><div><br></div><div>Or in R17:</div><div><br></div><div>FATAL ** Cannot load table foo from disc: {not_loaded, storage_unknown}<br></div><div><br></div><div>This then causes mnesia to shutdown.</div><div><br></div><div>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.</div><div><br></div><div>The active_replicas option for the table ends up listing the node() as well at some point.</div><div><br></div><div>I've attached a repo case.</div><div><br></div><div>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?</div><div><br></div><div>thanks,</div><div>vlad </div><div><br></div><div><br></div></div>
</div><br></div>