[rt-users] Upgrade problem.

Ruslan Zakirov ruz at bestpractical.com
Fri May 9 12:20:05 EDT 2008


Sounds like a bug, but I don't understand how to reproduce it. Can you
describe step by step how to reproduce the problem, so I can turn on
SQL logging and find it myself. I just don't get with which page I
should work and where start debugging.

On Fri, May 9, 2008 at 7:48 PM, J.P. Racine <racinejp at vianet.ca> wrote:
> I don't think that this would be related - we have no saved searches at
> all.   The single resolved ticket display tries to return all resolved..
> we have ~250K resolved tickets in this db and it looks to be returning
> all resolved tickets instead of just 1.  The tickets aren't displayed
> but the page is trying to get them.
>
> mysql> SELECT count(*) FROM Tickets main  WHERE (main.Status !=
> 'deleted') AND (main.Status = 'resolved') AND (main.EffectiveId =
> main.id) AND (main.Type = 'ticket')  ORDER BY main.id ASC;
> +----------+
> | count(*) |
> +----------+
> |   234766 |
> +----------+
>
> mysql> select status, count(*) from Tickets GROUP BY status;
> +----------+----------+
> | status   | count(*) |
> +----------+----------+
> | deleted  |     7919 |
> | new      |     1785 |
> | open     |      624 |
> | rejected |    23641 |
> | resolved |   237938 |
> | stalled  |      367 |
> +----------+----------+
>
> ( a few tickets may or may not have been resolved between those 2 queries ).
>
> Ruslan Zakirov wrote:
>> I think it's related to different handling of Rows attribute of a
>> saved search in 3.4 and 3.6. In 3.6 those are unlimited what me be
>> desired in some cases. Check that all saved searches have correct
>> number of rows. For searches on the at glance page use Edit link then
>> another link to edit it for all users, check value and save search.
>>
>> On Thu, May 8, 2008 at 11:51 PM, J.P. Racine <racinejp at vianet.ca> wrote:
>>
>>> Greetings,
>>>
>>> I've just upgraded an RT installation from 3.4.4 to 3.6.6 and found that
>>> although the schema hasn't changed that there are some SQL queries that
>>> seem to behave strangely.  The database is about 9 gigs in size and is
>>> runing on mysql 5 ( mysql-server-5.0 debian package 5.0.51a-3~bpo40+1 ).
>>>
>>> After the upgrade we noticed some strange behavior when trying to view a
>>> ticket that was in a resolved state.  The query below was called when
>>> the problem occured and and seem to return *all* resolved tickets and
>>> that was a bit to much for the memory of the system to handle.
>>>
>>> http://hostname.domain.com/Ticket/Display.html?id=123456
>>>
>>> SELECT main.* FROM Tickets main  WHERE (main.Status != 'deleted') AND
>>> (main.Status = 'resolved') AND (main.EffectiveId
>>> = main.id) AND (main.Type = 'ticket')  ORDER BY main.id ASC
>>>
>>> The same database is running fine ( albeit a bit slow ) with a
>>> production 3.4.4 install. Any pointers or suggestions to remedy this
>>> problem would be appreciated.  I just don't see why there is a query
>>> with no limit for no apparent reason returning unlimited results.
>>>
>>> Thanks,
>>>
>>> JP
>>>
>>>
>>>
>>> _______________________________________________
>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>
>>> Community help: http://wiki.bestpractical.com
>>> Commercial support: sales at bestpractical.com
>>>
>>>
>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>>> Buy a copy at http://rtbook.bestpractical.com
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>



-- 
Best regards, Ruslan.



More information about the rt-users mailing list