Well, I've never written to this table before or after converting it to a fragmented table. When you say "this" can happen are you referring to the problem that Chandru said? That I've somehow ended up with records in the wrong fragment?
Sent from my iPhone
On Jul 6, 2013, at 5:17 AM, Evgeny M <> wrote:
>> This may happen if you used dirty_write functions, even if you did this in activity with mnesia_frag callback
>> пятница, 5 июля 2013 г., 19:07:35 UTC+4 пользователь Noah Schwartz написал:
>>>> I have a table of type set that worked fine as a non-fragmented table. We started seeing performance issues with the table and with the anticipation of more clients in the system, we were worried the size would exceed the 2 GB max.
>>>> The table contains chat messages and we purge records older than 7 days. There seem to be a number of keys that don't show up in a read activity but, do show up when doing a table dump, a select, or using qlc to find records. As such, when this purge policy runs records are found that when I try to delete don't actually get deleted. It almost seems like read/delete are working off of one set while qlc is working off of another set.
>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130706/23cd93e4/attachment.html>