[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