[erlang-questions] WHOLETABLE lock on schema

[Dan Gudmundsson]

Thanks for the bug report.

I think this is a better patch :-)
I will include it in the next release.

/Dan

--- mnesia_dumper.erl	Thu May 24 09:45:01 2007
+++ mnesia_dumper.erl@@/mnesia-4.3.4	Thu Mar 22 12:05:25 2007
@@ -491,10 +491,10 @@
      Cs = mnesia_schema:list2cs(TabDef),
      Val = mnesia_schema:insert_cstruct(Tid, Cs, true), % Update ram only
      {schema, Tab, _} = Val,
-    case lists:member(N, val({current, db_nodes})) of
-	true when InitBy /= startup  ->
+    if
+	InitBy /= startup ->
  	    mnesia_controller:add_active_replica(Tab, N, Cs);
-	_ ->
+	true ->
  	    ignore
      end,
      if
@@ -760,11 +760,6 @@
  			     case mnesia_lib:cs_to_storage_type(Node, Cs) of
  				 Storage -> NS;
  				 disc_copies when Node == node() ->
-				     Dir = mnesia_lib:dir(),
-				     ok = mnesia_schema:opt_create_dir(true, Dir),
-				     mnesia_schema:purge_dir(Dir, []),
-				     mnesia_log:purge_all_logs(),
-
  				     mnesia_lib:set(use_dir, true),	
  				     mnesia_log:init(),
  				     Ns = val({current, db_nodes}),




Hal Snyder wrote:
> Follow-up to previous post:
> 
> I see the same problem in R-11B and R-9C, the two releases we are  
> running here. In both cases, I wonder if the problem is not the  
> following:
> 
> mnesia_locker.erl / receive_wlocks sits in a receive and can wait  
> forever if one of the nodes passed in its first argument is not  
> running. The following seems to make the problem go away .... but I'm  
> sure I know just enough to be dangerous:
> 
> receive_wlocks([Node | Tail], Res, Store, Oid) ->
>      receive
>          {?MODULE, Node, granted} ->
>              del_debug(Node),
>              receive_wlocks(Tail, Res, Store, Oid);
> ...
> +   after WlockTimeoutMsec ->
> +           del_debug(Node),
> +           Reason1 = {aborted, {node_timed_out, Node}},
> +           flush_remaining(Tail, Node, Reason1)
>      end;
> 
> 
> On May 23, 2007, at 10:58 AM, Hal Snyder wrote:
> 
>> I am seeing a stuck lock on the schema of a mnesia database. I'm  
>> not sure how it's happening yet. We run two nodes with disc_copies  
>> of the schema and several more with ram_copies of it, but I think  
>> all the nodes in question are listed in running_db_nodes.
>>
>> Here is another way to create the lock. I don't think this is what  
>> is happening to the problem system above, but it would be nice to  
>> know if there is a good way to resolve the general problem without  
>> downtime:
>>
>> N='some_fictional_node@REDACTED'.
>> mnesia:add_table_copy(schema, N, ram_copies).
>> mnesia:change_table_copy_type(schema, N, disc_copies).
>> mnesia:change_table_copy_type(schema, N, ram_copies).
>> -- at this point, erlang shell does not come back
>> -- you can interrupt it or remote in, though
>>
>> Last line could probably be anything that wants to lock the schema.  
>> For example,
>>   mnesia:create_table(baz,[]).
>> does the same thing.
>>
>> If you remote in from another node, you can do
>>   mnesia:system_info(held_locks).
>> and you will see something like this:
>>   [{{schema,'______WHOLETABLE_____'},write,{tid,5,<4163.81.0>}}]
>>
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>