[erlang-bugs] LATEST.LOG grows without limits on a Mnesia node which stores only RAM tables

Marek Majkowski <>
Wed Jul 6 13:06:14 CEST 2011

In some cases, on a two-node erlang cluster, LATEST.LOG grows and isn't
collected on a node which handles only ram mnesia tables.

LATEST.LOG seems to contain only transaction metadata, like:
$ mnesia_log:view().

I was able to reproduce this situation on stock Ubuntu R13B03 and R14B01.
In order to trigger this behaviour a transaction needs to span across
two tables, one of them needs to be  ram/ram, the other disc/ram. Like:

 [*] uno: [{,disc_copies},{,ram_copies}]
 [*] duo: [{,ram_copies},{,ram_copies}]

    G = fun() ->
                mnesia:delete({uno, a}),
                mnesia:delete({duo, a})

(record 'a' doesn't even need to be in the tables, so this
deletion is essentially a no-op)

In this case, LATEST.LOG on a node  (which doesn't have
any disc_copies table) will grow without bounds:

$ ls -la /
total 172104
       154  DECISION_TAB.LOG
 176211786  LATEST.LOG
      7233  schema.DAT

See attached code for a full test case.

   Marek Majkowski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.erl
Type: text/x-erlang
Size: 1311 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20110706/5ac8e978/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b.erl
Type: text/x-erlang
Size: 924 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20110706/5ac8e978/attachment-0001.bin>

More information about the erlang-bugs mailing list