Auto-incremented user id is incrementing wildly

I noticed this shortly after installing RT and forgot about it. Today’s
talk of SQL optimization had me looking at the database again.

mysql> select id from Users;
| id |
| 1 |
| 10 |
| 12 |
| 22 |
| 45 |
| 60 |
| 162 |
| 224 |
| 246 |
| 280 |
| 298 |
| 324 |
| 330 |
| 396 |
| 398 |
| 400 |
| 406 |
| 412 |
| 414 |
| 416 |
| 418 |
| 420 |
| 422 |
| 440 |
| 446 |
| 460 |
| 470 |
27 rows in set (0.00 sec)

According to show table status, the next id will be 471.

I have not deleted any users by hand. Around the jump from 60 to 160 I
moved from mysql 3 to mysql 4. This started as rt 3.0.3 and is now rt
3.0.4 and the move also coincides with the 60 -> 160 jump. However, you
will note that even before then the numbers bounced around a bit.

User ids and group ids are both fed by the primary key sequence from
Principals. There’s nothing wrong.On Wed, Aug 06, 2003 at 03:22:32PM -0700, Sean Perry wrote:

I noticed this shortly after installing RT and forgot about it. Today’s
talk of SQL optimization had me looking at the database again.

mysql> select id from Users;
±----+
| id |
±----+
| 1 |
| 10 |
| 12 |
| 22 |
| 45 |
| 60 |
| 162 |
| 224 |
| 246 |
| 280 |
| 298 |
| 324 |
| 330 |
| 396 |
| 398 |
| 400 |
| 406 |
| 412 |
| 414 |
| 416 |
| 418 |
| 420 |
| 422 |
| 440 |
| 446 |
| 460 |
| 470 |
±----+
27 rows in set (0.00 sec)

According to show table status, the next id will be 471.

I have not deleted any users by hand. Around the jump from 60 to 160 I
moved from mysql 3 to mysql 4. This started as rt 3.0.3 and is now rt
3.0.4 and the move also coincides with the 60 → 160 jump. However, you
will note that even before then the numbers bounced around a bit.


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Jesse Vincent wrote:

User ids and group ids are both fed by the primary key sequence from
Principals. There’s nothing wrong.

fair enough. Can you please explain why the group number is so high
when we have 2 groups: it.admin and staff?

This one time, at band camp, Sean Perry wrote:

fair enough. Can you please explain why the group number is so high
when we have 2 groups: it.admin and staff?

If I remember correctly, a group is any unique set of principals, and thus
whenever you have a set of principals you need a new unique group. Thus for
each ticket you have at least 4 new groups created: the Requestor group, the
CC group, the AdminCC group and, er, something else that eludes me right
now. So, your number of groups is going to be at least 4 times the number
of tickets.

jaq@spacepants.org http://spacepants.org/jaq.gpg

Hi!

If I remember correctly, a group is any unique set of principals, and thus
whenever you have a set of principals you need a new unique group. Thus for
each ticket you have at least 4 new groups created: the Requestor group, the
CC group, the AdminCC group and, er, something else that eludes me right
now.
Owner, of course :slight_smile:

So, your number of groups is going to be at least 4 times the number
of tickets.

Alexey Rusakov aka Ktirf
RingRows OOO