| Age | Commit message (Collapse) | Author |
|---|
|
* dgud/mnesia/read-sticky-bug/OTP-9786:
[mnesia] Read record from correct node
[mnesia] Fixed sticky read lock bug
[mnesia] Whitespace fixes
Conflicts:
lib/mnesia/src/mnesia_log.erl
|
|
* rc/mnesia_log-no-async:
Use the synchronous log_terms instead of alog_terms in mnesia_log:ets2dcd()
OTP-9804
|
|
This avoids the situation where mnesia could dump a very large ets table in
its entirety into the message queue of the disk_log process, causing memory
blowup and choking the disk logger.
|
|
Read from where_to_read otherwise bad data may read during
move_table, where where_to_write is updated before where_to_read
and the table is available.
|
|
wread on locks stuck at non-local node could return unexpected value.
Thanks to Magnus Henoch who posted a nice testcase showing the bug.
|
|
|
|
create_table
|
|
* pr/mnesia_frag_hash:
add mnesia_frag_hash test
Reduce calls to phash in key_to_frag_number
OTP-9722
|
|
|
|
|
|
|
|
Allow schema operation even if not all nodes are upgraded to
latest version.
|
|
|
|
Aviods failing/wobbling testcase. Mnesia mishandled supervisors.
|
|
|
|
|
|
|
|
* dgud/mnesia/leaking-log/OTP-9551:
[mnesia] Use api to log decisions.
|
|
Mainly to correctly clear dets tables. It may also be faster to use
the dedicated functions.
|
|
Instead of just appending decisions to the log, use mnesia_log:log(Decision),
it will increment the counter which causes the log to be dumped even
if no actual commits are stored on this node.
This fixed a bug where the LATEST.log would grow forever on a node which
had the schema on disc, but where not involved in any commits.
|
|
|
|
|
|
|
|
And remove old protocol version hacks
|
|
The do_merge_schema function now converts cstructs from a remote node
when it detects that they are different. In order to be compatible the
other way around, mnesia_controller:get_cstructs() detects a remote caller,
and converts the cstructs before sending them.
|
|
|
|
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
|
|
|
|
|
|
* uw/mnesia-majority:
dialyzer warning on mnesia_tm
Add documentation text about majority checking
add mnesia_majority_test suite
where_to_wlock optimization + change_table_majority/2
bug in mnesia_tm:needs_majority/2
optimize sticky_lock maj. check
check majority for sticky locks
Write locks now check majority when needed.
Add {majority, boolean()} per-table option.
OTP-9304
|
|
|
|
|
|
|
|
|
|
|
|
Since the table loader also sets (table) write locks, a special
lock type, 'load', was needed. Unfortunately, this affects mnesia
activity callbacks that redefine the lock operation.
|
|
With {majority, true} set for a table, write transactions will
abort if they cannot commit to a majority of the nodes that
have a copy of the table. Currently, the implementation hooks
into the prepare_commit, and forces an asymmetric transaction
if the commit set affects any table with the majority flag set.
In the commit itself, the transaction will abort if it cannot
satisfy the majority requirement for all tables involved in the
thransaction.
A future optimization might be to abort already when a write
lock is attempted on such a table (/-object) and the lock cannot
be set on enough nodes.
This functionality introduces the possibility to automatically
"fence off" a table in the presence of failures.
This is a first implementation. Only basic tests have been
performed.
|
|
* dgud/mnesia/add_index_crash/OTP-9285:
Fix mnesia crash when adding index on non loaded tables.
|
|
Fixes timing issue in test cases
|
|
This could happen on ram_copies tables.
|
|
Original code calls phash 1..2 times, based on which fragment the hashed key
targets and how many fragments exist. New code always calls phash only once.
|
|
|
|
|
|
|
|
|
|
"When I run mnesia:first on an empty fragmented table, it tries to
access the fragment with the number one beyond the maximum. In the
sample code below, I create a table with two fragments, 'foo' and
'foo_frag2', but mnesia tries to access 'foo_frag3':"
|
|
|
|
|
