[erlang-questions] Mnesia doesn't report insertion errors when underlying DETS file is full?

Éric Pailleau eric.pailleau@REDACTED
Sat May 23 14:25:20 CEST 2015


Hi, 
Thanks Ulf.
It would be probably more smart to warn before to loose data...
A system event 'almost_full' should be more convenient. It is sometime better to stop the application instead loose data.
An event on each last 5 percent change could allow to handle different actions. Mail, SMS, or ultimately stop the application on almost_full_99. 
There is already an event on database inconsistency, it would be a nice enhancement.
Regards 

Le 23 mai 2015 13:02, Ulf Wiger <ulf@REDACTED> a écrit :
>
>
> > On 23 May 2015, at 10:38, Éric Pailleau <eric.pailleau@REDACTED> wrote: 
> > 
> > Just wanted to know if mnesia subscribe on system events can raise a 
> > 
> > {mnesia_error, Format, Args} 
> > 
> > In such case ? 
>
> It *almost* does, if you set mnesia’s debug level to ‘verbose’. ;-) 
>
> The following call is made from mnesia_tm if do_update_op/3 crashes: 
>
>             verbose("do_update in ~w failed: ~p -> {'EXIT', ~p}~n", 
>                     [Tid, Op, Reason]), 
>
> …which, in its turn ends up calling the following in mnesia_lib: 
>
> important(Format, Args) -> 
>     save({Format, Args}), 
>     report_system_event({mnesia_info, Format, Args}). 
>
> The only problem is that the dets operation in question doesn’t crash, but instead returns {error, Reason}, so that particular issue won’t be reported. The value *is* captured by mnesia_tm:do_update/4, and it will return the last non-ok value from the commit. However, this return value is discarded, except in a few cases where it’s captured as debug info. 
>
> Of course, even if it were reported, it would be of the category “oops - your database was just corrupted!”, which is good to know, but not so easy to handle. 
>
> BR, 
> Ulf W 
>
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. 
> http://feuerlabs.com 
>
>
>


More information about the erlang-questions mailing list