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

[Marek Majkowski]

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().
{decision,{tid,32746729,<7505.131.0>},committed,[],[rbt2@REDACTED]}
{decision,{tid,32746731,<7505.133.0>},
          unclear,
          [rbt1@REDACTED],
          [rbt2@REDACTED]}
{decision,{tid,32746731,<7505.133.0>},
          committed,
          [rbt1@REDACTED],
          [rbt2@REDACTED]}


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: [{a@REDACTED,disc_copies},{b@REDACTED,ram_copies}]
 [*] duo: [{a@REDACTED,ram_copies},{b@REDACTED,ram_copies}]

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

(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 b@REDACTED (which doesn't have
any disc_copies table) will grow without bounds:

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

See attached code for a full test case.

Cheers,
   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>