[erlang-questions] WHOLETABLE lock on schema

[Hal Snyder]

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>}}]
>