Hello Marc,
Marc Alff a écrit, Le 04.08.2009 20:14:
> #At file:///home/malff/BZR-TREE/mysql-azalea-perfschema/ based on
> revid:marc.alff@stripped
>
> 2848 Marc Alff 2009-08-04
> Bug#45496 Performance schema: assertion fails in ha_perfschema::rnd_init:223
>
> Implemented review comments for rnd_init(),
> which also resolves bug 45496
> === modified file 'storage/perfschema/ha_perfschema.cc'
> --- a/storage/perfschema/ha_perfschema.cc 2009-07-21 21:55:48 +0000
> +++ b/storage/perfschema/ha_perfschema.cc 2009-08-04 18:14:07 +0000
> @@ -245,10 +245,10 @@ int ha_perfschema::rnd_init(bool scan)
>
> DBUG_ASSERT(m_table_share);
> DBUG_ASSERT(m_table_share->m_open_table != NULL);
> - DBUG_ASSERT(m_table == NULL);
>
> stats.records= 0;
> - m_table= m_table_share->m_open_table();
> + if (m_table == NULL)
> + m_table= m_table_share->m_open_table();
> if (m_table)
> {
> /* Unsafe for binlog */
So if we are in the scenario of this comment of handler.h:
/**
rnd_init() can be called two times without rnd_end() in between
(it only makes sense if scan=1).
then the second call should prepare for the new table scan (e.g
if rnd_init allocates the cursor, second call should position it
to the start of the table, no need to deallocate and allocate it again
*/
i.e. two calls to rnd_init() without rnd_end() in between, then the
comment suggests that the second call should reset something ("position
it to the start of the table").. Here I have the impression that by
skipping m_open_table() we are skipping some important pieces of it,
like resetting positions (m_pos...) to the start of the table.
Isn't there really any problem?
I'm not asking for a fix because I have not identified a problem; it
just looks "suspicious" to me.
Thanks!
