Re: [Maria-developers] 0310b44: MDEV-10418 Assertion `m_extra_cache' failed in ha_partition::late_extra_cache(uint)
Hi, Alexey! On Dec 20, Alexey Botchkov wrote:
revision-id: 0310b444dba1b9cbd6921963dd3bff689ca23a24 (mariadb-5.5.53-34-g0310b44) parent(s): f23b41b9b8a30e0e54a1ec7a8923057b0e57e0f5 committer: Alexey Botchkov timestamp: 2016-12-20 00:24:20 +0400 message:
MDEV-10418 Assertion `m_extra_cache' failed in ha_partition::late_extra_cache(uint)
The m_extra_prepare_for_update parameter should be set to FALSE as the query ends.
This seems fairly obvious, that it should. But why MySQL doesn't have this bug (despite not resetting m_extra_prepare_for_update)?
diff --git a/sql/ha_partition.cc b/sql/ha_partition.cc index 15fa7d1..4374354 100644 --- a/sql/ha_partition.cc +++ b/sql/ha_partition.cc @@ -6667,6 +6667,7 @@ int ha_partition::reset(void) DBUG_ENTER("ha_partition::reset"); if (m_part_info) bitmap_set_all(&m_part_info->used_partitions); + m_extra_prepare_for_update= FALSE; file= m_file; do {
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
This seems fairly obvious, that it should. But why MySQL doesn't have this bug (despite not resetting m_extra_prepare_for_update)?
The difference is in the ha_partition::late_extra_cache() function MySQL: if (m_extra_prepare_for_update) { (void) file->extra(HA_EXTRA_PREPARE_FOR_UPDATE); } Maria: if (m_extra_prepare_for_update) { DBUG_ASSERT(m_extra_cache); (void) file->extra(HA_EXTRA_PREPARE_FOR_UPDATE); } And that DBUG_ASSERT() actually does the crash. MySQL just blindly does the file->extra(HA_EXTRA_PREPARE_FOR_UPDATE) even for that 'SELECT * FROM t2;' query. Best regards. HF 21.12.2016 0:35, Sergei Golubchik wrote:
Hi, Alexey!
On Dec 20, Alexey Botchkov wrote:
revision-id: 0310b444dba1b9cbd6921963dd3bff689ca23a24 (mariadb-5.5.53-34-g0310b44) parent(s): f23b41b9b8a30e0e54a1ec7a8923057b0e57e0f5 committer: Alexey Botchkov timestamp: 2016-12-20 00:24:20 +0400 message:
MDEV-10418 Assertion `m_extra_cache' failed in ha_partition::late_extra_cache(uint)
The m_extra_prepare_for_update parameter should be set to FALSE as the query ends. This seems fairly obvious, that it should. But why MySQL doesn't have this bug (despite not resetting m_extra_prepare_for_update)?
diff --git a/sql/ha_partition.cc b/sql/ha_partition.cc index 15fa7d1..4374354 100644 --- a/sql/ha_partition.cc +++ b/sql/ha_partition.cc @@ -6667,6 +6667,7 @@ int ha_partition::reset(void) DBUG_ENTER("ha_partition::reset"); if (m_part_info) bitmap_set_all(&m_part_info->used_partitions); + m_extra_prepare_for_update= FALSE; file= m_file; do { Regards, Sergei Chief Architect MariaDB and security@mariadb.org
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Hi, Alexey! I see :) Thanks! On Feb 21, Alexey Botchkov wrote:
This seems fairly obvious, that it should. But why MySQL doesn't have this bug (despite not resetting m_extra_prepare_for_update)?
The difference is in the ha_partition::late_extra_cache() function MySQL: if (m_extra_prepare_for_update) { (void) file->extra(HA_EXTRA_PREPARE_FOR_UPDATE); }
Maria: if (m_extra_prepare_for_update) { DBUG_ASSERT(m_extra_cache); (void) file->extra(HA_EXTRA_PREPARE_FOR_UPDATE); }
And that DBUG_ASSERT() actually does the crash.
MySQL just blindly does the file->extra(HA_EXTRA_PREPARE_FOR_UPDATE) even for that 'SELECT * FROM t2;' query.
Best regards. HF
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Alexey Botchkov -
Sergei Golubchik