Straneg bug in group membership 3.2.2

Bug is as follows:

When deleting a group member the apache-perl process goes into a
tail-spin, slowly eating all memory (it is not very fast, around 700MB
in 30 seconds on a dual opteron). No action seems to be taken. Stracing
the process shows running selects versus the database without doing much
else.

I tried to work out where the group ID is stored in the database, but I
have to admit that I am possibly too stupid.

I see two locations in the db - GroupMembers and CachedGroupMembers. If
you delete the relevant entry from both the user goes away, but still
appears as an AdminCc when working on a ticket. It picks it up from
somewhere else, if someone knows from where it will be much appreciated.

I ended up disabling the group and recreating it under a new name which
fixed the problem.

Has anybody else seen this? (I am currently digging through the
archives, but have not found this particular one yet).

A.

Anton Ivanov wrote:

Bug is as follows:

When deleting a group member the apache-perl process goes into a
tail-spin, slowly eating all memory (it is not very fast, around 700MB
in 30 seconds on a dual opteron). No action seems to be taken. Stracing
the process shows running selects versus the database without doing much
else.
Could you turn on SQL logging in your DB and send us query log?
Could you try 3.2.3rc1 from
Index of /pub/rt/devel and see if this fixed there.

[snip]