maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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@xxxxxxxxxxx>
> committer: Varun Gupta <varun.gupta@xxxxxxxxxxx>
> 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@xxxxxxxxxxx