Hi, Varun! On Aug 26, Varun Gupta wrote:
revision-id: 25d6f575a50 (mariadb-10.4.7-31-g25d6f575a50) parent(s): 7b4de10477a author: Varun Gupta <varun.gupta@mariadb.com> committer: Varun Gupta <varun.gupta@mariadb.com> timestamp: 2019-08-22 02:38:38 +0530 message:
MDEV-19705: Assertion `tmp >= 0' failed in best_access_path
The reason for hitting the assert is that rec_per_key estimates have some garbage value. So the solution to fix this would be for long unique keys to use use rec_per_key for only 1 keypart
--- mysql-test/main/long_unique.result | 15 +++++++++++++++ mysql-test/main/long_unique.test | 14 ++++++++++++++ sql/table.cc | 13 ++++++++++++- 3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/sql/table.cc b/sql/table.cc index 1ab4df0f7cf..fa57693e7eb 100644 --- a/sql/table.cc +++ b/sql/table.cc @@ -828,6 +829,16 @@ static bool create_key_infos(const uchar *strpos, const uchar *frm_image_end, { keyinfo->key_length= HA_HASH_KEY_LENGTH_WITHOUT_NULL; key_part++; // reserved for the hash value + /* + but hash keys have a flag "only whole key", so for hash keys one should never + look at keyinfo->rec_per_key for partial keys, and they cannot possibly be calculated + so here we make sure that the keyinfo->rec_per_key[keyinfo->user_defined_key_parts-1] + would point to the slot we reserved for the keyinfo which holds the unique key with + hash + */ + ulong *dest= (keyinfo->rec_per_key + keyinfo->user_defined_key_parts - 1); + memcpy(&dest, &rec_per_key, sizeof(ulong*));
Sorry, I don't understand what you're doing here. I only meant something like keyinfo->rec_per_key-= keyinfo->user_defined_key_parts - 1;
+ *rec_per_key++= 0; }
/*
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org