PDA

View Full Version : Install fails due to giant "assignable users" datastore query


Cars2007
Wed 31st Oct '07, 3:38pm
In adminfunctions_projecttools.php in function build_assignable_users, there is a query:

$users = $db->query_read($sql="
SELECT user.userid, user.username
FROM " . TABLE_PREFIX . "user AS user
INNER JOIN " . TABLE_PREFIX . "usergroup AS usergroup ON (user.usergroupid = usergroup.usergroupid)
WHERE (user.usergroupid IN (" . implode(',', $assigntype) . ")
OR FIND_IN_SET(" . implode(', user.membergroupids) OR FIND_IN_SET(', $assigntype) . ", user.membergroupids))
AND (usergroup.genericoptions & " . $vbulletin->bf_ugp_genericoptions['isnotbannedgroup'] . ")
ORDER BY user.username
");The query, when actually generated by PHP, looks like this:
SELECT user.userid, user.username
FROM user AS user
INNER JOIN usergroup AS usergroup ON (user.usergroupid = usergroup.usergroupid)
WHERE (user.usergroupid IN (1,2,3,4,5,6,7,15,16,17)
OR FIND_IN_SET(1, user.membergroupids) OR FIND_IN_SET(2, user.membergroupids) OR FIND_IN_SET(3, user.membergroupids) OR FIND_IN_SET(4, user.membergroupids) OR FIND_IN_SET(5, user.membergroupids) OR FIND_IN_SET(6, user.membergroupids) OR FIND_IN_SET(7, user.membergroupids) OR FIND_IN_SET(15, user.membergroupids) OR FIND_IN_SET(16, user.membergroupids) OR FIND_IN_SET(17, user.membergroupids))
AND (usergroup.genericoptions & 32)
ORDER BY user.usernameThis results in the $users array containing every member on the board, which subsequently goes into the $assignable array. This is then serialized into a gigantic string and then sent to build_datastore('pt_assignable', serialize($assignable), 1);

build_datastore tries to send this mammoth serialized object with 25,000+ usernames in it to MySQL, which results in this error message:

Invalid SQL:

REPLACE INTO datastore
(title, data, unserialize)
VALUES
('pt_assignable', 'a:1:{i:1;a:3:{s:3:\"bug\";a:2 (rest of line removed)

MySQL Error : MySQL server has gone away
Error Number : 2006The size of the serialized data is 1,934,499 bytes. MySQL's max packet size is the default, 1,048,576. So, the server closes its connection, resulting in the "server has gone away" message.

If it is a matter of increasing the max packet size, that is OK with me, but I thought it might be a bug that it's creating a permissions object that encompasses every user on the board.

Steve Machol
Wed 31st Oct '07, 3:58pm
I would increase the max packet size to 2M. I do not know if this is normal or not but to get fedback from the Devs on this you can report this in the 3.6 Bug Tracker here:

http://www.vbulletin.com/forum/project.php?projectid=6

FWIW you can also read this for the main reasons for the MySQL server going away:

http://www.vbulletin.com/forum/showthread.php?s=&postid=310265#post310265

Cars2007
Wed 31st Oct '07, 7:21pm
Bug opened: http://www.vbulletin.com/forum/project.php?issueid=23446

Zachery
Wed 31st Oct '07, 8:09pm
A mysql packet size of 1 or 2m is pretty small, most servers use something between 8/16mb.