For the record, I've found out what was causing this.<br><br>A process was regularly executing ets:safe_fixtable(true) on this table, and not finishing off with ets:safe_fixtable(false).<br><br>This meant that the behaviour of mnesia:dirty_first was affected, and was also causing increased memory consumption.<br>


<br>Thanks to Håkan and Sverker for helping me find the root cause.<br><br>cheers<br>Chandru<br><br><div class="gmail_quote">On 1 July 2011 14:44, Chandru <span dir="ltr"><<a href="mailto:chandrashekhar.mullaparthi@gmail.com" target="_blank">chandrashekhar.mullaparthi@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br><br>One of my production nodes running R12B-5 is exhibiting some strange behaviour. <br><br>mnesia:dirty_read(gtp_tid, mnesia:dirty_first(gtp_tid)).<br>


<br>gives me an empty list. The table has 39K entries. How do I find out what is happening? I tried using ets operations directly and get the same result (which is what mnesia is doing behind the scenes anyway). I get the same empty result using a transaction to read. Any clues?<br>



<br>96> ets:info(gtp_tid).<br>[{memory,213857900},<br> {owner,<0.741.0>},<br> {name,gtp_tid},<br> {size,39088},<br> {node,node@server},<br> {named_table,true},<br> {type,set},<br> {keypos,2},<br> {protection,public}]<br>



<br>The same operation works ok on other tables.<br><br>cheers<br><font color="#888888">Chandru<br><br>
</font></blockquote></div><br>