Bug #42559 More than 32 index/tup scan on one fragment can cause timeouts (or lcp-hang)

Submitted: 2 Feb 2009 21:06 Modified: 3 Feb 2009 12:34
Reporter: Jonas Oreland Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: Jonas Oreland CPU Architecture:Any

[2 Feb 2009 21:06] Jonas Oreland
Description:
If doing more than 32 index *or* tup-scan on one fragment
scans could be left hanging too long, this can
cause unnecessary timeouts, and/or worst case hanging LCP

this was introduced by fix for bug#42084

problem was that they share ScanNo - range (used for ScanTakeOver)

and when an index-scan finishes it will only start queued index-scans
(or when an tup-scan finishes it will only start queued tup-scans)

solution is to split the ScanNo range
(so that acc scan has one range, tux scan has one range and tup scan has one range)

How to repeat:
run testScan --l 1000 -n 488O T1
while running LCP on highest speed, note that it doesnt run continuously

Suggested fix:
split range
[2 Feb 2009 21:21] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/64939

2806 Jonas Oreland	2009-02-02
      ndb - bug#42559
[2 Feb 2009 21:31] Bugs System
Pushed into 5.1.31-ndb-6.4.3 (revid:jonas@mysql.com-20090202213027-xfip15kq57fu9klj) (version source revid:jonas@mysql.com-20090202213027-xfip15kq57fu9klj) (merge vers: 5.1.31-ndb-6.4.3) (pib:6)
[2 Feb 2009 21:31] Bugs System
Pushed into 5.1.31-ndb-6.2.17 (revid:jonas@mysql.com-20090202212134-uhk6g48lz95m4nc5) (version source revid:jonas@mysql.com-20090202212134-uhk6g48lz95m4nc5) (merge vers: 5.1.31-ndb-6.2.17) (pib:6)
[2 Feb 2009 21:32] Bugs System
Pushed into 5.1.31-ndb-6.3.22 (revid:jonas@mysql.com-20090202212343-opce431gg4wqivq4) (version source revid:jonas@mysql.com-20090202212343-opce431gg4wqivq4) (merge vers: 5.1.31-ndb-6.3.22) (pib:6)
[3 Feb 2009 12:34] Jon Stephens
Documented in the NDB-6.2.17, 6.3.22, and 6.4.2 changelogs as follows:

        When performing more than 32 index or tuple scans on a single 
        fragment, the scans could be left hanging. This caused unnecessary 
        timeouts, and in addition could possibly lead to a hang of an LCP.

        This bug was introduced by the fix for Bug #42084.
[4 Feb 2009 12:35] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/65148

2810 Jonas Oreland	2009-02-04
      ndb - test prg for bug#42559
[4 Feb 2009 12:44] Bugs System
Pushed into 5.1.31-ndb-6.2.17 (revid:jonas@mysql.com-20090204123522-5g0fd31u7mu83gej) (version source revid:jonas@mysql.com-20090204123522-5g0fd31u7mu83gej) (merge vers: 5.1.31-ndb-6.2.17) (pib:6)
[4 Feb 2009 12:44] Bugs System
Pushed into 5.1.31-ndb-6.3.22 (revid:jonas@mysql.com-20090204124039-4239bv0cmqq7kr0v) (version source revid:jonas@mysql.com-20090204124039-4239bv0cmqq7kr0v) (merge vers: 5.1.31-ndb-6.3.22) (pib:6)
[4 Feb 2009 12:46] Bugs System
Pushed into 5.1.31-ndb-6.4.3 (revid:jonas@mysql.com-20090204124234-btvep0nz9e2vk030) (version source revid:jonas@mysql.com-20090204124234-btvep0nz9e2vk030) (merge vers: 5.1.31-ndb-6.4.3) (pib:6)
[9 Feb 2009 9:32] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/65578

3248 Martin Skold	2009-02-09 [merge]
      Merge
[10 Feb 2009 20:13] Bugs System
Pushed into 6.0.10-alpha (revid:alik@sun.com-20090210194937-s7xshv5l3m1v7wi9) (version source revid:tomas.ulin@sun.com-20090204130805-wb1egwdby2y0cnti) (merge vers: 6.0.10-alpha) (pib:6)

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.066 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.