MySQL Bugs: #59013: Partition handler loses information about HA_STATUS_NO

Bug #59013	Partition handler loses information about HA_STATUS_NO_LOCK
Submitted:	17 Dec 2010 20:41	Modified:	7 Jan 2011 22:10
Reporter:	Mikael Ronström	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Partitions	Severity:	S2 (Serious)
Version:	5.5.8	OS:	Any
Assigned to:	Mikael Ronström	CPU Architecture:	Any

Description:
When the partition handler gets an ::info call with a flag
HA_STATUS_NO_LOCK it doesn't pass this flag on to the underlying
handler thus causing InnoDB to get high contention since it has
to get the delete_length when the NO_LOCK flag isn't set.

How to repeat:
Run DBT2 with InnoDB as underlying handler and table is partitioned.
Use the Poor Man's profiler which reports almost half threads locked
in getting deleting length in ha_innodb::info_low.

Suggested fix:
Make sure that partition handler doesn't lose flags in ::info call.

It would be advantegous to also add a new flag HA_STATUS_VARIABLE_EXTRA
to indicate that delete_length and possibly other info must be filled in.
Without this flag set it's ok to to not update delete_length.

Pushed into mysql-trunk 5.6.2 (revid:mikael@dator8-20110103154543-ltnrlm80y2s0s3dr) (version source revid:mikael@dator8-20110103154543-ltnrlm80y2s0s3dr) (merge vers: 5.6.2) (pib:24)

Pushed into mysql-5.5 5.5.9 (revid:mikael@dator8-20110103145904-7b8j3z5pmu6t4jj9) (version source revid:mikael@dator8-20101217205840-i7ltx8m6z3uc42kh) (merge vers: 5.5.9) (pib:24)

Documented as follows in the 5.5.9 and 5.6.2 changelogs:

        The partitioning handler did not pass locking information to a
        table's storage engine handler. This caused high contention and 
        thus slower performance when working with partitioned InnoDB 
        tables.

Closed.

Already documented in 5.5.9 -- setting back to Closed.