<p>Hi,</p>
<p>As CGM table have more records to account recursive members then you should filter out some records. Use Via = id and GroupId <> MemberId condition on CGM table.</p>
<p>Regards, Ruslan. From phone.</p>
<div class="gmail_quote">2010 11 16 02:51 пользователь "Jesse Vincent" <<a href="mailto:jesse@bestpractical.com">jesse@bestpractical.com</a>> написал:<br type="attribution">> <br>> <br>> <br>> On Mon, Nov 15, 2010 at 04:52:58PM -0500, Josh Narins wrote:<br>
>> Sorry, wasn't obvious I sent anything last time because of spurious signature insertion.<br>>> <br>>> > From: Jesse Vincent [mailto:<a href="mailto:jesse@bestpractical.com">jesse@bestpractical.com</a>]<br>
>> > Sent: Monday, November 15, 2010 4:27 PM<br>>> > On Mon, Nov 15, 2010 at 04:24:22PM -0500, Josh Narins wrote:<br>>> > > Through admin error, during a practice migration of Postgres to<br>
>> > > Oracle[1], about 5% of the GroupMembers table was deleted[2].<br>>> ><br>>> > Is the cached-group-members table intact? You can likely recover all<br>>> > the data from that, though I'm late for a plane. Someone else may be<br>
>> > able to recommend exact steps to do so.<br>>> <br>>> The cached-group-members table is intact!<br>> <br>> Basically, the cachedgroupmembers table has a superset of the columns in the groupmembers table.<br>
> <br>> If you grab only the columns in cachedgroupmembers that match groupmembers, remove the id column and unique the set, then you should be able to insert those rows into the groumembers table. then run rt-validator and test the heck out of things.<br>
</div>