Hologres:Notable fixes

Niveau

Description

Cause

Versions concernées/corrigées

Solution de contournement

P1

Après avoir modifié le nombre de réplicas de shard pour une instance, celle-ci redémarre brièvement. Exemple SQL :

--The instance briefly restarts.
CALL HG_CREATE_TABLE_GROUP ('tg', 1);
CALL HG_UPDATE_DATABASE_PROPERTY ('default_table_group', 'tg');
CALL hg_set_table_group_property ('tg', 'replica_count', '2'); 

Lorsque vous modifiez le nombre de réplicas de shard, les métadonnées ne se mettent pas à jour correctement, ce qui provoque le redémarrage de l'instance.

Versions concernées :

• V2.1.1 à V2.1.10

• V2.0.33 et versions antérieures

Versions corrigées :

• V2.1.11 et versions ultérieures

• V2.0.34

Mettez à jour vers la dernière version.

P2

Si une importation de données utilisant la procédure stockée hg_insert_overwrite échoue, la procédure ne nettoie pas la table temporaire qu'elle a créée.

La procédure stockée hg_insert_overwrite crée une table temporaire lors de son exécution mais manque d'un mécanisme de nettoyage, ce qui laisse la table en place si la tâche échoue.

Versions concernées :

V2.0.19 et versions antérieures

Versions corrigées :

V2.0.30 et versions ultérieures

• Supprimez manuellement la table temporaire.

• Mettez à jour vers la dernière version.

P2

L'utilisation d'un plan fixe pour écrire des données dans une colonne DECIMAL dans Hologres peut entraîner des données incorrectes. Ce problème survient si la valeur d'entrée est un nombre négatif et que la différence entre sa décimale la moins significative et l'échelle de la colonne de destination est de 19 ou plus. Exemple SQL :

CREATE TABLE fixed_plan_decimal (col decimal(38,19));

-- A write error is triggered because the input value is negative and the difference between its least significant decimal place and the destination column's scale is 19.
INSERT INTO fixed_plan_decimal VALUES (-1.000000000);

-- The written result is 7922816250.4264337593543950336.
SELECT * FROM fixed_plan_decimal;
 

Ce problème survient car le chemin du plan fixe gère incorrectement la précision du type DECIMAL, ce qui entraîne des erreurs de données.

Versions concernées :

V2.1.11 et versions antérieures

Versions corrigées :

V2.1.12 et versions ultérieures

• Lors de l'écriture des données, convertissez explicitement la valeur d'entrée vers le type DECIMAL correct, par exemple : -1.000000000::decimal(38,19).

• Mettez à jour vers la dernière version.

P1

Pour les instances avec binlog activé, l'utilisation du CPU augmente considérablement après une mise à niveau vers la V2.1.9.

Après la mise à niveau d'une instance avec binlog activé vers la V2.1.9, le binlog peut ne pas détecter correctement les erreurs dans certains scénarios. Cet échec empêche le processus de se terminer normalement après une erreur, ce qui entraîne une journalisation excessive et une augmentation de l'utilisation du CPU.

Versions concernées :

V2.1.1 à V2.1.9

Versions corrigées :

V2.1.10 et versions ultérieures

Mettez à jour vers la dernière version.

Niveau

Description

Cause

Versions

Recommandations

P1

La fonction var_samp renvoie une variance incorrecte lorsque le type de données d'entrée est DECIMAL. Exemple SQL :

CREATE TABLE t1(f1 decimal(38,18));
    INSERT INTO t1 VALUES (123),(234),(456);

    -- The result for the DECIMAL type is incorrect.
    SELECT var_samp(f1) FROM t1;
    -- The following result is returned:
    var_samp   
    --------------
     0.2382402695

    -- The result is correct after the type is converted to INT.
    SELECT var_samp(f1::int) FROM t1;
    -- The following result is returned:
    var_samp     
    ------------------
     28749.0000000000
     

Une erreur de conversion de type se produit dans la fonction var_samp lors du traitement des données DECIMAL.

Concernées :

V2.0.27 et versions antérieures.

Corrigées :

V2.0.28 et versions ultérieures.

Mettez à jour vers la dernière version.

Niveau

Description

Cause

Versions concernées et corrigées

Solution de contournement

P2

L'utilisation de la fonction date_part avec un champ en majuscules provoque l'erreur error: unsupport extract type xxx.

SELECT date_part('HOUR',ts) FROM tt;
    --error:unsupport extract type [HOUR]

L'échec de la requête est dû au fait que l'optimiseur n'a pas correctement reconnu le champ en majuscules dans la fonction date_part.

Versions concernées :

V2.0.1 à V2.0.25

Version corrigée :

V2.0.26 et versions ultérieures

Effectuez une mise à niveau vers la dernière version.

P2

L'utilisation de l'opérateur && pour concaténer des tableaux renvoie l'erreur suivante : Unexpected expr type in array expr:145.

CREATE TABLE test (
      channel_info text
    );
    SELECT regexp_split_to_array(LOWER('TMK'),',') && array[(regexp_split_to_array(LOWER(channel_info),'-'))[2]]  FROM test;

    --error:Unexpected expr type in array expr:145

Le moteur d'exécution de l'opérateur && est Hologres Query Engine (HQE). Lorsque l'opérateur && est utilisé avec un tableau, l'optimiseur traite incorrectement ce dernier. Cela génère un plan d'exécution erroné et entraîne l'échec de la requête.

Versions concernées :

V2.0.25 et versions antérieures

Version corrigée :

V2.0.26 et versions ultérieures

Effectuez une mise à niveau vers la dernière version.

P2

Pour une table partitionnée, une instruction with qui ne sélectionne aucune partition renvoie des alias de colonne incorrects.

CREATE TABLE t0_parent(ds text, v1 bigint, v2 bigint, v3 bigint) PARTITION BY list (ds);
    CREATE TABLE t0_child1 PARTITION OF t0_parent FOR VALUES IN ('20230915');
    CREATE TABLE t0_child2 PARTITION OF t0_parent FOR VALUES IN ('20230916');

    --Query statement that selects 0 partitions
    WITH cte1 AS (
      SELECT v1, v2, v3 FROM t0_parent
    ),
        cte2 AS (
          SELECT v1, v2 FROM cte1 WHERE v3 = 1 AND v3 = 2
        )
        SELECT v2 AS vb, v1 AS va FROM cte2 limit 1;

    --Incorrect result with the wrong alias 
     v2 | v1 
    ----+----

    --Correct result with the right alias
    vb | va 
    ----+----

Pour une requête comportant une clause with cte sur une table partitionnée, si la requête ne sélectionne aucune partition, l'optimiseur de requêtes (QO) supprime incorrectement les nœuds de partition lors de la génération du plan d'exécution. Cette erreur entraîne la perte des alias de colonne dans l'ensemble de résultats.

Versions concernées :

V2.0.25 et versions antérieures

Version corrigée :

V2.0.26 et versions ultérieures

Effectuez une mise à niveau vers la dernière version.

P2

Si une instruction case when utilise le type DECIMAL et contient également une fonction traitée par PQE, une erreur se produit :

error: column with id 0 has type decimal(38, 10) but ReadColumn returns array Array(type=decimal(20, 4) length=1 null_count=0 [1.0000]).

Lorsqu'une instruction case when contient à la fois un type DECIMAL et une fonction exécutée par Parallel Query Engine (PQE), le système ne parvient pas à convertir correctement la précision du type DECIMAL. L'incompatibilité résultante provoque l'échec de la requête.

Versions concernées :

V2.0.23 et versions antérieures

Version corrigée :

V2.0.24 et versions ultérieures

Effectuez une mise à niveau vers la dernière version.

P2

L'insertion de données dans une table enfant échoue avec l'erreur Can't find parent table for table name si sa table parente se trouve dans un schéma différent.

CREATE schema haha;
    CREATE TABLE haha.p(
      a text not null, 
      b int not null
    ) PARTITION BY LIST(a);
    CREATE TABLE public.c1 PARTITION OF haha.p FOR VALUES IN('v1');

    insert into public.c1 SELECT 'v1', generate_series(0 100);
    --error:Can't find parent table for table name

Bien que Hologres prenne en charge les tables parentes et enfants situées dans des schémas différents, le système n'a pas réussi à identifier cette relation lors d'une opération INSERT, ce qui a entraîné l'échec de l'insertion.

Versions concernées :

V2.0.23 et versions antérieures

Version corrigée :

V2.0.24 et versions ultérieures

Effectuez une mise à niveau vers la dernière version.

P2

Une importation en masse utilisant insert on conflict do update pouvait créer des clés primaires en double sur une table orientée ligne. Ce problème survenait lorsque la clé de clustering et la clé primaire (PK) de la table étaient différentes et qu'aucune durée de vie (TTL) n'était explicitement définie.

--Create table statement
    BEGIN ;
    CREATE TABLE test (
      id integer,
      phone_number text,
      create_time text
      ,PRIMARY KEY (id)
    );
    CALL set_table_property('test', 'orientation', 'row');
    CALL set_table_property('test', 'storage_format', 'sst');
    CALL set_table_property('test', 'clustering_key', 'create_time:asc');
    CALL set_table_property('test', 'distribution_key', 'id');
    CALL set_table_property('test', 'time_to_live_in_seconds', '3153600000');
    COMMIT ;

    --Duplicate primary keys appear during query
    SELECT * FROM test;
    id | phone_number |create_time
    ---|--------------|-----------
    1  | 134xxxx      | 2023-11-06 19:25:42.483287+08
    1  | 134xxxx      | 2023-11-06 19:25:42.483287+08

Sur une table orientée ligne, insert on conflict do update marque un enregistrement pour suppression avant d'en insérer un nouveau. Si la clé primaire (PK) et la clé de clustering étaient différentes, la compaction ne traitait pas correctement le fichier marqué pour suppression, ce qui entraînait la duplication des clés primaires.

Versions concernées :

V2.0.22 et versions antérieures

Version corrigée :

V2.0.23 et versions ultérieures

• Définissez la même valeur pour la clé primaire (PK) et la clé de clustering de la table orientée ligne, ou convertissez la table en une table orientée colonne.

• Effectuez une mise à niveau vers la dernière version.

P2

Une requête effectuant un group by sur une colonne issue d'une expression array_to_string(array_sort(...)) et incluant plusieurs agrégations count(distinct ...) échoue avec l'erreur suivante : ORCA failed to produce a plan : No plan has been computed for required properties.

create table t1 (f1 int , f2 int , f3 int , f4 text[]);

    SELECT 
    f1,f5,
    count(distinct f2),
    count(distinct f3)
    FROM 
    (
      SELECT f1,f2,f3,array_to_string(array_sort(f4),',')as f5 FROM t1
    )tt
    group by f1,f5;

count(distinct ...) génère une expression de table commune (CTE), mais la fonction array_sort ne prend pas en charge l'intégration des CTE. Cette incompatibilité empêche l'optimiseur de créer un plan d'exécution valide, ce qui provoque l'échec de la requête.

Versions concernées :

V2.0.22 et versions antérieures

Version corrigée :

V2.0.23 et versions ultérieures

Effectuez une mise à niveau vers la dernière version.

P2

Certaines requêtes se bloquent après l'exécution de la commande drop server.

L'exécution de la commande drop server a provoqué l'échec de l'opération de relecture entre les nœuds FE. Les décalages de version résultants entre les nœuds ont entraîné le blocage des requêtes.

Versions concernées :

V1.3.40 à V1.3.51

Version corrigée :

V1.3.52 et versions ultérieures

Effectuez une mise à niveau vers la dernière version.

Niveau

Description

Cause

Versions

Solution de contournement

P2

Lors de l'utilisation d'un index vectoriel Proxima, l'insertion d'un vecteur nul sans utiliser de plan fixe entraîne une erreur d'écriture : internal error: check condition "and_handle_null" assert failed. Voici un exemple de requête SQL :

BEGIN;
    CREATE TABLE t (
      vector float4[] CHECK (array_ndims(vector) = 1 AND array_length(vector, 1) = 3)
    );
    CALL SET_TABLE_PROPERTY ('t', 'proxima_vectors', '{"vector":{"algorithm":"Graph","distance_method":"SquaredEuclidean"}}');
    END;

    set hg_experimental_enable_fixed_dispatcher = off;

    -- Insert a null vector
    INSERT INTO t values (null);
    -- ERROR:  internal error: check condition "and_handle_null" assert failed.

En mode sans plan fixe, l'écriture d'une valeur de vecteur nul provoque un échec d'assertion lors de l'opération CHECK (array_ndims(vector).

Versions concernées :

V2.0.21 et antérieures

Versions corrigées :

V2.0.22 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P1

Après avoir activé le chiffrement du stockage pour un projet MaxCompute, l'interrogation des données MaxCompute depuis une table étrangère Hologres échoue de manière intermittente avec l'une des erreurs suivantes : query next FROM foreign table executor failed, Channel is empty ou internal error: Connect timeout.

Dans Hologres V2.0.15, une correction apportée à un problème lié aux transferts de clés lors du déchiffrement des données MaxCompute a introduit un bogue de corruption de mémoire multithread. Lorsqu'une table étrangère MaxCompute subit une évolution de schéma, ce bogue peut provoquer un plantage (coredump) et un redémarrage du composant SQE, entraînant des erreurs intermittentes lorsque l'application accède à la table étrangère.

Versions concernées :

V2.0.15 à V2.0.20

V1.3.61 à V1.3.62

Versions corrigées :

V2.0.21 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

L'utilisation de la fonction string_agg sur un champ avec une contrainte not null provoque une erreur : Column column0 should be non-nullable but the values contain 1 nulls. Voici un exemple de requête SQL :

create table test(id int not null, msg text not null);    insert into test values (1, 'b');SELECT count(distinct id), string_agg(distinct id::text) FROM test where msg = 'a';

La sortie de string_agg peut être null, mais l'optimiseur de requêtes (QO) déduit si le résultat est null en fonction des propriétés des champs qu'il traite. Lorsqu'un champ est not null, le QO déduit que le résultat de string_agg ne peut pas être nul, ce qui conduit à un résultat incorrect et génère un message d'erreur.

Versions concernées :

V2.0.20 et antérieures

Versions corrigées :

V2.0.21 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

Pour les instances comportant un grand nombre de groupes de tables et un nombre élevé de shards (supérieur à 100), les shards peuvent devenir inégalement répartis après une défaillance d'un worker. La distribution reste inégale même après l'exécution de la commande rebalance.

Lorsqu'une instance possède de nombreux groupes de tables et un nombre élevé de shards (supérieur à 100), la commande de rééquilibrage redistribue les shards de manière imprécise, sans parvenir à corriger la distribution inégale.

Versions concernées :

V2.0.20 et antérieures

Versions corrigées :

V2.0.21 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

L'utilisation de la fonction substring sur un champ de table contenant des données UTF-8 sur 4 octets produit un résultat incorrect. Toutefois, l'application de la fonction substring aux mêmes données UTF-8 sur 4 octets de manière indépendante fonctionne correctement. Voici un exemple de requête SQL :

-- Returns 3, which is correct.
    SELECT length(substring (E'\U0001F345' || '23456789', 1, 3));

    -- Using substring on table data returns an incorrect result.
    create table t (emoji text);
    insert into t values (E'\U0001F345' || '23456789');

    -- Returns 1, which is incorrect. The expected result is 3.
    SELECT length(substring(emoji, 1, 3)) FROM t;

L'implémentation actuelle de la fonction substring prend uniquement en charge les caractères UTF-8 d'une longueur maximale de 3 octets. Par conséquent, l'utilisation de substring sur des données de table contenant des caractères sur 4 octets renvoie un résultat incorrect.

Versions concernées :

V2.0.19 et antérieures

Versions corrigées :

V2.0.20 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

La consommation CPU augmente considérablement après l'activation de la consommation Binlog.

Des paramètres système par défaut mal configurés provoquent une journalisation système à haute fréquence lors de la consommation Binlog, augmentant ainsi l'utilisation du processeur.

Versions concernées :

V2.0.17 à V2.0.19

Versions corrigées :

V2.0.20 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

La fonction string_agg ou array_agg renvoie un résultat incorrect lorsqu'un filtre d'agrégation est utilisé. Voici un exemple de requête SQL :

• DDL et importation des données :

  create table test(x text, y int);insert into test values(null, 1), (null, 2),(null, 1), (null, 2);

• Requête 1 :

  SELECT array_agg(x) filter (where x is not null) FROM test group by y;
  -- Expected result: [null],[null]
  -- Actual (incorrect) result: {null},{null}

• Requête 2 :

  SELECT array_agg(x) filter (where x is  null) FROM test group by y;
  -- Expected result: {null,null},{null,null}
  -- Actual (incorrect) result: {null,null},{null}

Lorsqu'un filtre d'agrégation était utilisé avec string_agg ou array_agg, le filtre n'était pas traité correctement, ce qui entraînait des résultats incorrects ou instables.

Versions concernées :

V2.0.18 et antérieures

Versions corrigées :

V2.0.19 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

Lorsqu'une opération array_agg filter sur un champ avec la propriété not null produit un résultat contenant null, l'instance redémarre brièvement. Voici un exemple de requête SQL :

create table bbb(x int not null, y int);insert into bbb values (1, 1);SELECT array_agg(x) filter (where x > 1) FROM bbb group by y;

Lors de l'utilisation de array_agg filter sur un champ not null, l'optimiseur de requêtes (QO) a déduit à tort que le résultat devait également être not null. Si le résultat réel contenait une valeur null, ce conflit provoquait un plantage (coredump) de l'instance.

Versions concernées :

V2.0.18 et antérieures

Versions corrigées :

V2.0.19 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P1

Lors de l'utilisation de Proxima, la définition du paramètre min_flush_proxima_row_count sur 0 provoque le redémarrage de l'instance.

Pour le moteur de stockage (SE) Hologres, la valeur du paramètre min_flush_proxima_row_count doit être supérieure à 0. Si vous définissez min_flush_proxima_row_count sur 0, la vérification SE échoue, ce qui entraîne le redémarrage de l'instance.

Versions concernées :

V2.0.18 et antérieures

Versions corrigées :

V2.0.19 et ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

Après avoir activé la création automatique de partitions, si vous déplacez une table vers un autre schéma puis créez une nouvelle table portant le même nom dans le schéma d'origine, une erreur se produit : ERROR: auto_partitioning.time_unit could only be specified once. Voici un exemple de requête SQL :

-- Enable automatic partitioning
    begin;
    CREATE TABLE ads.test (
      olap_date integer NOT NULL default 0,
      pk text NOT NULL default ''::text,
      sid text  ,
    PRIMARY KEY (olap_date, pk))
      PARTITION BY LIST (olap_date);
    CALL set_table_property('ads.test', 'auto_partitioning.enable', 'true');
    CALL set_table_property('ads.test', 'auto_partitioning.time_unit', 'day');
    CALL set_table_property('ads.test', 'auto_partitioning.time_zone', 'PRC');
    CALL set_table_property('ads.test', 'auto_partitioning.num_precreate', '4');
    CALL set_table_property('ads.test', 'auto_partitioning.num_retention', '33');
    CALL set_table_property('ads.test', 'auto_partitioning.num_hot', '15');
    commit;

    -- Change the schema of the table
    alter table test set schema to public;

    -- Recreate the table with the same name
    begin;
    CREATE TABLE ads.test (
      olap_date integer NOT NULL default 0,
      pk text NOT NULL default ''::text,
      sid text  ,
    PRIMARY KEY (olap_date, pk))
      PARTITION BY LIST (olap_date);
    CALL set_table_property('ads.test', 'auto_partitioning.enable', 'true');
    CALL set_table_property('ads.test', 'auto_partitioning.time_unit', 'day');
    CALL set_table_property('ads.test', 'auto_partitioning.time_zone', 'PRC');
    CALL set_table_property('ads.test', 'auto_partitioning.num_precreate', '4');
    CALL set_table_property('ads.test', 'auto_partitioning.num_retention', '33');
    CALL set_table_property('ads.test', 'auto_partitioning.num_hot', '15');
    commit;

    ERROR: auto_partitioning.time_unit could only be specified once

Après avoir activé la création automatique de partitions, lorsque le schéma d'une table est modifié, sa configuration de partitionnement automatique ne suit pas le déplacement. Cela provoque un conflit de configuration et une erreur si une nouvelle table portant le même nom est créée dans le schéma d'origine.

Versions concernées :

V2.0.18 et antérieures

Versions corrigées :

V2.0.19 et ultérieures

Effectuez la mise à niveau vers la dernière version.

Niveau

Description

Cause

Versions concernées et corrigées

Solution de contournement

P2

L'utilisation de la fonction Concat avec un argument de colonne unique provoque une erreur : Function concat node must have at least 2 arguments but it only has 1. Exemple :

create table aaa(x text);insert into aaa values ('11111111');SELECT concat(x) FROM aaa;HGERR_msge internal error: Function concat node must have at least 2 arguments but it only has 1

Les versions antérieures ne prennent pas en charge l'utilisation de la fonction Concat avec un argument de colonne unique.

Versions concernées :

V2.0.17 et antérieures.

Versions corrigées :

V2.0.18 et ultérieures.

Effectuez la mise à niveau vers la dernière version.

P1

Après l'activation du stockage froid pour une table partitionnée, l'exécution d'une opération alter schema, telle que add column, sur la table de partition parente peut entraîner un comportement inattendu lors de la conversion des tables de partition enfant vers le stockage froid. Les problèmes spécifiques peuvent inclure les éléments suivants :

• Le statut du transfert de certaines tables de partition enfant vers le stockage froid reste transferring.

• Les tables enfant censées être converties en stockage froid ne le sont pas. Par exemple, si vous définissez une politique pour convertir les tables enfant âgées de plus de 10 jours en stockage froid, certaines de ces tables peuvent rester en stockage chaud.

• Les tables enfant déjà en stockage froid sont signalées à tort comme étant en stockage chaud.

Pour les tables partitionnées avec le stockage froid activé, si vous exécutez la commande alter schema sur la table parente, l'opération s'applique également aux tables enfant. Cela rend les propriétés de stockage des tables de partition enfant incohérentes entre le nœud FE et le gestionnaire de métadonnées (SM). Les tables enfant sont marquées pour le stockage froid dans le nœud FE, mais possèdent un mode de stockage différent dans le SM. Par conséquent, les actions de stockage froid pour les tables enfant ne fonctionnent pas comme prévu. Vous pouvez utiliser l'instruction SQL suivante pour récupérer les tables de stockage froid qui ne se comportent pas comme attendu :

SELECT db_name, schema_name, table_name FROM hologres.hg_table_info where collect_time::date = date '20230901' and table_meta::json#>>'{table_storage_mode}' = 'cold' and hot_storage_size > 0 order by table_name;

Versions concernées :

V2.0.17 et antérieures.

Versions corrigées :

V2.0.18 et ultérieures.

• Modifiez la propriété de stockage des tables enfant concernées au sein d'une seule transaction. Par exemple :

  begin;call set_table_property('schema.<cold_child_table_name>', 'storage_mode', 'hot');call set_table_property('schema.<cold_child_table_name>', 'storage_mode', 'cold');commit;

• Effectuez la mise à niveau vers la dernière version.

  Remarque

  Après la mise à niveau, vous devez corriger manuellement les propriétés de stockage des tables enfant affectées avant la mise à niveau.

P2

Une instance secondaire en lecture seule ne peut pas consommer le Binlog Hologres.

Une modification d'une propriété par défaut de l'instance secondaire en lecture seule est à l'origine de ce problème.

Versions concernées :

Premières versions de V1.3 et V2.0.

Versions corrigées :

V1.3.61 et ultérieures ; V2.0.17 et ultérieures.

Utilisez l'instance principale pour consommer le Binlog Hologres, ou effectuez la mise à niveau vers une version corrigée.

P2

Lorsqu'une colonne est comparée à des constantes de types différents à l'aide de or, par exemple col::type = const1::type1 or col::type = const2::type2, la requête peut renvoyer un ensemble de résultats vide ou des résultats inattendus. L'exemple SQL est le suivant :

create table t (a date, b timestamp, c text, d int);-- Column 'a' is a DATE type, but is implicitly cast to a TIMESTAMP type after the OR, leading to unexpected results.SELECT * FROM t where a in (timestamp '2023-06-12', timestamp '2023-06-13') or a = timestamp '2023-06-14';-- The data types on either side of the OR operator are inconsistent.SELECT * FROM t where a in (timestamp '2023-06-12', timestamp '2023-06-13') or a = '2023-06-14';

Si les types de données des champs connectés par or sont incohérents, l'optimiseur de requêtes (QO) n'aligne pas les types lors de la génération d'un plan d'exécution, ce qui fait que la sortie finale diffère du résultat attendu.

Versions concernées :

V1.3.59 et antérieures ;

V2.0.14 et antérieures.

Versions corrigées :

V1.3.60 et ultérieures ; V2.0.15 et ultérieures.

Effectuez la mise à niveau vers la dernière version.

P2

Dans une instance primaire-secondaire, l'exécution de HG_MOVE_TABLE_TO_TABLE_GROUP ou la définition d'une table en readonly peut rendre l'instance secondaire indisponible.

Étant donné que le mécanisme Lazy Open est activé sur l'instance secondaire, après avoir effectué un resharding sur l'instance principale ou défini manuellement readonly sur true puis écrit à nouveau des données, le statut des shards des instances primaire et secondaire devient incohérent, ce qui rend l'instance secondaire indisponible.

Versions concernées :

V1.3.42 à V2.0.16.

Versions corrigées :

V2.0.17 et ultérieures.

• Pour effectuer une opération de resharding ou définir une table en lecture seule, désactivez d'abord le mécanisme Lazy Open sur l'instance secondaire en exécutant ces commandes :

  SELECT hg_admin_command('set_global_flag', 'enable_dynamic_close_tablet=false');    SELECT hg_admin_command('set_global_flag', 'enable_lazy_open_tablet=false');

  Après avoir appliqué ces paramètres, redémarrez l'instance. Cette nouvelle configuration peut légèrement augmenter l'utilisation de la mémoire.

Niveau

Description

Cause

Versions concernées et corrigées

Solution de contournement

P1

Les requêtes utilisant le moteur PQE échouent avec l'erreur suivante :

ERROR: status { code: SERVER_INTERNAL_ERROR message: "query next FROM pg executor failed FROM xxx: ERPC_ERROR_CONNECTION_CLOSED, reason: Drain packet failed, peer address:xxx" }

Un bogue intermittent dans le processus PQE provoquait des fuites de processus lors du traitement des requêtes SQL. Lorsque le nombre de processus en fuite atteignait la limite de 512, l'instance ne pouvait plus traiter les nouvelles requêtes.

Versions concernées :

V2.0.1 à V2.0.11.

Versions corrigées :

V2.0.12 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Un cluster partagé échoue à lire les données chiffrées depuis ODPS et signale l'erreur suivante :

error query next FROM foreign table executor failed, pangu://xxxx validate userinfo fail xxxx.

Les clusters partagés ne prennent pas en charge les données chiffrées.

Versions concernées :

V2.0.15 et antérieures.

Versions corrigées :

V2.0.16 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Une opération de sauvegarde et de restauration échoue si l'instance source contient une table de stockage à froid faisant l'objet d'écritures fréquentes.

Les écritures fréquentes dans une table de stockage à froid déclenchent une compaction continue des données. Étant donné que la méthode de sauvegarde sans interruption nécessite un alignement des versions des shards, cette compaction continue empêche le processus de sauvegarde de capturer le dernier état des shards et provoque l'échec de la sauvegarde.

Versions concernées :

V2.0.15 et antérieures.

Versions corrigées :

V2.0.16 et ultérieures.

• Convertissez la table de stockage à froid soumise à des écritures fréquentes en table de stockage à chaud avant la sauvegarde. Pour plus d'informations, consultez stockage hiérarchisé des données.

• Mettez à niveau vers la dernière version.

P2

Une instance redémarre brièvement après l'annulation manuelle ou l'expiration du délai d'une requête SQL PQE.

Les requêtes SQL PQE sont gourmandes en ressources. Une requête annulée manuellement ou ayant expiré peut ne pas se terminer correctement, ce qui entraîne une erreur de pointeur nul et un vidage mémoire (coredump) de l'instance.

Versions concernées :

V2.0.12 à V2.0.14.

Versions corrigées :

V2.0.15 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Une requête case when contenant un type array[] renvoie le message d'erreur suivant :

Filter has x rows but length of columns is y.

Lorsque l'instruction case when traite un champ de type array[], certaines données au sein du tableau array[] sont perdues, ce qui provoque une erreur de requête.

Versions concernées :

V2.0.10 et antérieures.

Versions corrigées :

V2.0.11 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Après avoir exécuté une opération DROP sur une table avec la journalisation binaire activée et redémarré l'instance, le stockage de l'instance ne diminue pas et l'utilisation du stockage signalée par la surveillance est supérieure au résultat de la requête pg_database_size.

Après la suppression (DROP) d'une table avec binlog activé, le redémarrage de l'instance empêche la suppression correcte du répertoire du binlog de la table, ce qui empêche la diminution de l'utilisation du stockage.

Versions concernées :

V2.0.12 et antérieures.

Versions corrigées :

V2.0.13 et ultérieures.

Mettez à niveau vers la dernière version.

P2

La spécification d'un ordre asc ou desc pour une clé de distribution lors de la création d'une table provoque des erreurs de requête ou des redémarrages brefs de l'instance. Exemple :

BEGIN ;CREATE TABLE test(a int);CALL set_table_property('test', 'distribution_key', 'a:asc');COMMIT ;

La clé de distribution ne prend pas en charge la spécification d'un ordre asc ou desc. Cela a entraîné l'échec de la relecture de l'instruction DDL sur le FE, provoquant un vidage mémoire (coredump) ou des erreurs lors de l'interrogation ou de l'écriture dans la table.

Versions concernées :

V1.3.55 et antérieures.

Versions corrigées :

V1.3.56 et ultérieures.

• Ne spécifiez pas d'ordre asc ou desc lors de la création d'une clé de distribution.

• Mettez à niveau vers la dernière version pour résoudre le problème de vidage mémoire. Après la mise à niveau, une erreur invalid distribution column: xx:asc est signalée si vous spécifiez asc/desc pour la clé de distribution lors de la création d'une table.

Niveau

Description

Cause

Versions concernées et corrigées

Solutions de contournement

P2

En mode SLPM, lorsque vous utilisez la fonction slpm_alter_view_owner pour créer deux vues portant le même nom dans des schémas différents, la fonction signale une erreur : ERROR: more than one row returned by a subquery used as an expression.

call slpm_enable();call slpm_enable_multi_schema_view();create schema test_schema;create table tb1(id int);create view public.v1 as SELECT * FROM public.tb1;create view test_schema.v1 as SELECT * FROM public.tb1;

En mode SLPM, la création d'une vue entre plusieurs schémas fait référence à la table système pg_class. Si des vues portant le même nom existent dans différents schémas, la colonne relname de pg_class contient des valeurs en double. Cela amène la sous-requête à renvoyer plusieurs lignes, ce qui déclenche une erreur.

Versions concernées :

V2.0.3 à V2.0.9.

Versions corrigées :

V2.0.10 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Après l'activation du stockage à froid, une instance secondaire en lecture seule redémarre brièvement lorsqu'elle accède à une table de stockage à froid.

L'instance secondaire en lecture seule ne dispose pas des variables d'environnement requises pour le stockage à froid, ce qui provoque une erreur lors de la tentative d'accès à une table de stockage à froid.

Versions concernées :

V1.3.54 et antérieures.

Versions corrigées :

V1.3.55 et ultérieures.

• Convertissez la table de stockage à froid en table de stockage standard.

• Mettez à niveau vers la dernière version.

P2

Après la mise à niveau d'une instance Hologres vers la version V1.3, si vous créez une table étrangère Hologres dans MaxCompute et utilisez la double signature pour accéder aux instances Hologres dans les régions Chine (Shanghai) et États-Unis (Virginie), les requêtes échouent avec l'erreur suivante :

ERROR: pooler: xxxx: authentication failed.

Après la mise à niveau, une erreur de configuration de l'environnement dans les régions Chine (Shanghai) et États-Unis (Virginie) empêche MaxCompute de s'authentifier auprès de Hologres à l'aide de la double signature.

Versions concernées :

V1.3.54 et antérieures.

Versions corrigées :

V1.3.55 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Après la mise à niveau d'une instance Hologres vers la version V1.3, l'exécution de la commande suivante dans les régions Chine (Shanghai) et États-Unis (Virginie) indique que le nombre maximal de connexions pour un seul nœud n'est pas de 128.

show max_connections;

Après la mise à niveau, une erreur de configuration de l'environnement dans les régions Chine (Shanghai) et États-Unis (Virginie) a entraîné une divergence du nombre maximal de connexions pour un seul nœud par rapport à la valeur par défaut de 128.

Versions concernées :

V1.3.54 et antérieures.

Versions corrigées :

V1.3.55 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Après l'activation du masquage des données, une requête utilisant une expression de table commune (CTE) et UNION sur un champ masqué échoue avec l'erreur suivante :

ERROR: pooler: xxxx: remote server read/write error yy. Voici un exemple :

set hg_anon_enable = on;create table if not exists test_anon_cte(id text);security label for hg_anon on column test_anon_cte.id is 'hash';with tt2 as (SELECT * FROM test_anon_cte) SELECT count(1) FROM tt2 where id != 'a' group by id union all SELECT count(1) FROM tt2 where id != 'b' group by id;

Après l'activation du masquage des données, UNION ALL n'est pas pris en charge pour les champs masqués. Lors de l'utilisation d'une CTE et de UNION, la requête externe rencontre un pointeur nul. Cela provoque un vidage mémoire (coredump) de l'instance et l'échec de la requête.

Versions concernées :

V1.3.51 et antérieures.

Versions corrigées :

V1.3.52 et ultérieures.

Mettez à niveau vers la dernière version pour résoudre le vidage mémoire de l'instance. Toutefois, UNION reste non pris en charge pour les champs masqués et la requête échouera avec l'erreur UNION is not supported on security item.

P2

Après la mise à niveau de Hologres de la version V1.1 à la version V1.3, le résultat de cast array to text contient un caractère d'échappement (\), comme illustré dans l'exemple suivant :

create table arrary_to_text (  a text, b text, c text);insert into arrary_to_text values ('7416461', 'czzzzz', '2023-04-16 23:13:34');SELECT CAST(ARRAY_AGG(CONCAT('[','"', a,'"',',','"', b,'"',',','"', c,'"',']')) AS TEXT) AS list_vin FROM arrary_to_text limit 1;--Result in the latest V1.3 version"{"[\"7416461\",\"czzzzz\",\"2023-04-16 23:13:34\"]"}"--Result in V1.1"{"["7416461","czzzzz","2023-04-16 23:13:34"]"}"

Dans les versions de Hologres antérieures à la V1.3.51, la prise en charge de la conversion cast array to text était incomplète et n'ajoutait pas le caractère d'échappement (\). À partir de la version V1.3.51, Hologres a amélioré la prise en charge de cast array to text afin d'aligner son comportement sur le protocole PostgreSQL standard. Les résultats des requêtes contiennent désormais le caractère d'échappement (\), qui n'était pas présent dans les anciennes versions. Par conséquent, cette différence de résultats est attendue.

Versions concernées :

V1.3.50 et antérieures.

Versions corrigées :

V1.3.51 et ultérieures.

Il est normal que le résultat contienne un caractère d'échappement supplémentaire (\).

Niveau

Description

Cause

Versions concernées et corrigées

Solution de contournement

P2

L'exécution d'une instruction SQL contenant une jointure par boucle imbriquée (Nested Loop Join) renvoie une erreur : Schema has 1 fields but 2 are expected. Voici un exemple d'instruction SQL :

SELECT "_"."table_name"    FROM "public"."test" "_"    where "_"."table_name" = 'hello'     and (case when lower("_"."user_id") is not null        then lower("_"."user_id")        else ''        end) = 'ssss';

L'optimiseur de la version actuelle de Hologres supprime le projet supplémentaire, ce qui entraîne une inadéquation des colonnes dans la table et l'échec de la requête.

Versions concernées :

V1.3.45 et antérieures.

Versions corrigées :

V1.3.49 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Lors de la conversion de données du type TEXT vers le type JSON, les données qui ne sont pas dans un format JSON valide sont également converties de manière incorrecte. Voici un exemple d'instruction SQL :

create table test1(data text);insert into test1 values('{"a","b"}');SELECT data::json FROM test1;--Incorrect result: {"a","b"}

Le résultat correct devrait être une erreur : invalid input syntax for type json" detail: "Expected \":\", but found \",\".".

Lors d'une conversion de type text::json, le système traite ::json comme un cast. Cela amène le moteur d'exécution (QE) à ignorer la validation du format des données JSON et à convertir incorrectement les données au type JSON.

Versions concernées :

V1.3.20 à V1.3.46.

Versions corrigées :

V1.3.47 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Lorsque le résultat de la fonction to_number (qui renvoie un DECIMAL) est converti en STRING pour des calculs ultérieurs, le résultat final est incorrect. Voici un exemple d'instruction SQL :

create table test(x text);insert into test values ('0');SELECT (to_number(x, '9') || ' days')::interval FROM test;Result:-------0.E-10 days

Dans Hologres, la fonction to_number convertit 0.0000000000 en type TEXT, puis en notation scientifique, ce qui donne des résultats de requête incorrects car le moteur de calcul (QE) ne gère pas correctement la notation scientifique actuellement.

Versions concernées :

V1.3.44 et antérieures.

Versions corrigées :

V1.3.46 et ultérieures.

Mettez à niveau vers la dernière version.

P2

Les requêtes sur des types de tables spéciaux, tels que les tables MaxCompute Cluster et les tables Cfile, sont plus lentes que les requêtes sur les tables MaxCompute standard.

Dans la version actuelle, lors de la lecture des données depuis les tables MaxCompute Cluster ou Cfile, le moteur d'exécution de Hologres divise les petits fichiers de la table étrangère en fichiers encore plus petits. Cela augmente le nombre de fichiers traités dans une seule requête et ralentit les performances des requêtes.

Versions concernées :

V1.3.20 à V1.3.40.

Versions corrigées :

V1.3.45 et ultérieures.

Mettez à niveau vers la dernière version.

Niveau

Description

Cause

Versions concernées et corrigées

Solution de contournement

P0

Une instance redémarre lorsque vous modifiez les propriétés du schéma d'une table, telles que TTL, Bitmap ou Dictionary. L'exemple suivant modifie le TTL d'une table :

call set_table_property('tablename', 'time_to_live_in_seconds', '946080');

Si une instance est mise à niveau depuis une version antérieure, telle que la V1.1, les métadonnées historiques du schéma de certaines tables peuvent être manquantes. Le système peut tenter d'accéder à ces informations manquantes après une opération de vidage (flush) ou de compactage sur la table. La version actuelle ne gère pas correctement l'absence d'informations de schéma, ce qui déclenche un vidage mémoire (core dump).

Versions concernées :

V1.3.20 à V1.3.44

Versions corrigées :

V1.3.45 et versions ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

La fonction to_char(to_timestamp(hour)) renvoie un résultat incorrect — une heure plus tôt que l'heure réelle — lorsqu'elle est utilisée avec des données timestamptz antérieures au 1er janvier 1970. Voici un exemple d'instruction SQL :

create table t (a int);insert into t values (2);SELECT to_char(to_timestamp(a || '', 'HH24'), 'HH24:00:00') FROM t;

Le résultat obtenu est 01:00:00, alors que le résultat attendu est 02:00:00.

Le moteur d'exécution convertit incorrectement la précision temporelle lors du traitement des horodatages.

Versions concernées :

V1.3.20 à V1.3.43

Versions corrigées :

V1.3.44 et versions ultérieures

Effectuez la mise à niveau vers la dernière version.

P2

La conversion d'un type JSONB en type NUMERIC sans spécifier de précision entraîne l'échec de la requête avec l'erreur suivante : HGERR_msge numeric field overflow HGERR_detl A field with precision 0, scale 0 must round to an absolute value less than 1. HGERR_ctxt func_name:jsonb_numeric HGERR_end. Voici un exemple d'instruction SQL :

create table t1(f1 jsonb);insert into t1 values('1,1');SELECT f1::numeric FROM t1;

Lors de la conversion d'un type JSONB en type NUMERIC sans précision spécifiée, le plan d'exécution généré par l'optimiseur ne fournit pas de précision par défaut. Lorsque le moteur d'exécution convertit NUMERIC en DECIMAL dans ce scénario, il attribue par défaut une précision de 0,0, ce qui provoque l'échec de la requête.

Versions concernées :

V1.3.20 à V1.3.41

Versions corrigées :

V1.3.42 et versions ultérieures

• Spécifiez une précision lors de la conversion du type JSONB en type NUMERIC.

• Effectuez la mise à niveau vers la dernière version.

P2

L'interrogation des données d'un lac de données OSS échoue avec l'erreur suivante : query next FROM foreign table executor failed, Failed to call iterateForeignScan: ArrayIndexOutOfBoundsException.

Une fuite de mémoire dans le moteur de requête du lac de données Hologres lors de la lecture des données depuis OSS provoque l'échec de la requête.

Versions concernées :

V1.3.20 à V1.3.41

Versions corrigées :

V1.3.42 et versions ultérieures

Effectuez la mise à niveau vers la dernière version.

Niveau

Description

Cause

Versions concernées

Solution de contournement

P2

Lorsque vous utilisez union all sur deux champs décimaux dont la précision est incohérente, la requête échoue avec l'erreur : NUMERIC precision 65535 must be between 1 and 1000. Voici un exemple d'instruction SQL :

create table t1(a int ,b numeric(38,0), c bigint);create table t2(a int ,b numeric(38,0), c numeric(30,0));SELECT b / power(10, 18),c FROM t1UNION allSELECT a / power(10, a), c FROM t2

L'optimiseur de requêtes (QO) n'aligne pas la précision des champs décimaux dans une opération union all. Par conséquent, le moteur de requête (QE) détecte cette incohérence lors de l'exécution et renvoie une erreur.

Versions concernées :

V1.3.20 à V1.3.40.

Corrigé dans :

V1.3.41 et versions ultérieures.

Effectuez la mise à niveau vers la dernière version.

P2

L'exécution de la commande call set_table_property sur une table parent partitionnée existante au sein de la même transaction renvoie l'erreur : SET_TABLE_PROPERTY and CREATE TABLE statement are not in the same transaction for table . Voici un exemple d'instruction SQL :

--If the sample partitioned parent table exists, run the following SQL statement:
    BEGIN;
    CREATE TABLE IF NOT EXISTS "public".test ( "parent_node_id" text, "parent_node_name" text, "is_leaf" text, "node_flag" text, "ds" text) PARTITION BY LIST(ds);
    CALL SET_TABLE_PROPERTY('"public".test', 'orientation', 'row');
    COMMIT;

Dans les versions antérieures à Hologres V1.3.38, si une table parent partitionnée existe, l'utilisation de la commande set_table_property pour définir une propriété sur sa valeur existante amène le système à ignorer l'instruction SQL. Dans Hologres V1.3.38, la validation de set_table_property a été améliorée. En règle générale, vous ne pouvez pas modifier des propriétés telles que l'orientation, distribution_key et clustering_key pour les tables existantes. Toute tentative de modification de ces propriétés génère une erreur.

Versions concernées :

V1.3.38 à V1.3.40.

Corrigé dans :

V1.3.41 et versions ultérieures.

Effectuez la mise à niveau vers la dernière version.

P2

Les fonctions to_date, to_char et to_timestamp échouent lors du traitement de données comportant des espaces de tête, renvoyant l'erreur : HGERR_detl Field requires 4 characters, but only 0 could be parsed. Voici un exemple d'instruction SQL :

CREATE TABLE test2 (x text);
    INSERT INTO test2 VALUES (' 2022 03');
    SELECT to_date(x, 'YYYYMM')
    FROM test2;

Lorsque les données comportent des espaces de tête, les fonctions to_date, to_char et to_timestamp gèrent incorrectement ces espaces. Cela entraîne l'échec de la conversion des données et le renvoi d'une erreur par la requête.

Versions concernées :

V1.3.20 à V1.3.40.

Corrigé dans :

V1.3.42 et versions ultérieures.

• Modifiez l'instruction SQL pour gérer les espaces de tête. Par exemple : to_char(year, 'FM9999') .

• Effectuez la mise à niveau vers la dernière version.

Niveau

Description

Cause

Versions

Recommandation

P2

L'utilisation de la fonction rb_build avec un nom de table entraîne un échec et l'erreur suivante : Not support calling pg udf for type (23, LIST).

CREATE TABLE rb_build_test(a int[]);INSERT INTO rb_build_test VALUES ('{1,2,3}');SELECT rb_build(a) FROM rb_build_test;--Error: HGERR_code XX000 HGERR_msge internal error: Not support calling pg udf for type (23, LIST)

L'exécution directe de la fonction rb_build sans spécifier de nom de table aboutit à un résultat positif. Voici un exemple d'instruction SQL :

SELECT rb_build('{1,2,3}');--Result:rb_build\x3a300000010000000000020010000000010002000300                                

Lorsque la fonction rb_build est exécutée avec un nom de table, elle effectue d'abord les calculs, puis écrit les résultats dans la table. Cette fonction s'exécute dans HQE. L'échec survient car la version actuelle de HQE ne prend pas en charge la conversion bidirectionnelle entre les tableaux et les tableaux PQE.

Versions concernées :

V1.3.37 et versions antérieures.

Versions corrigées :

V1.3.38 et versions ultérieures.

Effectuez une mise à niveau vers la dernière version.

P2

Une requête SQL contenant une clause LIMIT x OFFSET y où y > x renvoie un nombre incorrect de lignes. Par exemple, la requête suivante devrait retourner deux lignes, mais elle n'en retourne aucune :

CREATE TABLE test (id int, msg text);INSERT INTO test VALUES (1, 'a'), (2, 'b'), (3, 'c'), (4, 'd');SELECT * FROM (SELECT * FROM test ORDER BY id LIMIT 2) x LIMIT 4 OFFSET 3;

Lors de la génération du plan d'exécution, si la valeur OFFSET dépasse la valeur LIMIT, le système propage la clause LIMIT vers l'opérateur, mais pas la clause OFFSET. Ce comportement entraîne un résultat de requête incorrect.

Versions concernées :

V1.3.20 à V1.3.36.

Versions corrigées :

V1.3.37 et versions ultérieures.

• Modifiez l'instruction SQL pour garantir que la valeur OFFSET soit inférieure à la valeur LIMIT.

• Effectuez une mise à niveau vers la dernière version.

P2

L'opération ANALYZE échoue avec l'erreur suivante : ERROR: store statistic results for table public.table_name failed: basic_string::_M_create.

L'opération ne parvient pas à analyser correctement les champs de la table.

Versions concernées :

V1.3.36.

Versions corrigées :

V1.3.37 et versions ultérieures.

Effectuez une mise à niveau vers la dernière version.

P2

La commande CREATE TABLE AS échoue avec l'erreur relation "xxx" does not exist lorsqu'elle est utilisée pour un schéma autre que public.

CREATE SCHEMA test_schema;SET search_path TO test_schema;CREATE TABLE test_src (a int);INSERT INTO test_src VALUES (1);CREATE TABLE AS test_src_1 SELECT * FROM test_src;--Error: relation "xxx" does not exist;

Après avoir utilisé la commande set search_path to pour spécifier un schéma, si le nom de la table dans la syntaxe create table as ne comporte pas de préfixe de schéma, le système recherche toujours la table source et insère les données dans le schéma public par défaut. Toutefois, un message d'erreur s'affiche car cette table n'existe pas dans le schéma public.

Versions concernées :

V1.3.20 à V1.3.36.

Versions corrigées :

V1.3.37 et versions ultérieures.

• Dans l'instruction CREATE TABLE AS, faites précéder le nom de la table par le schéma. Exemple :

  CREATE TABLE AS test_schema.test_src_1 SELECT * FROM test_src;

• Effectuez une mise à niveau vers la dernière version.

P2

Si vous définissez la valeur de départ d'un champ bigserial en dehors de la plage int4 (–2147483648 à 2147483647), les valeurs générées ultérieurement pour ce champ sont incorrectes.

CREATE TABLE IF NOT EXISTS test_tb(  id bigserial NOT NULL,  f1 text,  PRIMARY KEY (id,f1));--Insert data into the f1 field.INSERT INTO test_tb(f1) VALUES('1'),('2'),('3');-- Change the auto-increment starting value to 100 000 000 000.ALTER SEQUENCE public.test_tb_id_seq RESTART WITH 100000000000;-- Insert two more rows for testing.INSERT INTO test_tb(f1) VALUES('6'),('7');SELECT * FROM test_tb ORDER BY id ASC;--Result:id| f1------------+----1 | 12 | 23 | 31128270048 | 61128270049 | 7

La plage prise en charge pour la valeur de départ d'un type bigserial correspond à la plage int4 (–2147483648 à 2147483647). Si la valeur de départ spécifiée dépasse cette plage, un dépassement de précision se produit, ce qui entraîne des résultats incorrects.

Versions concernées :

V1.3.20 à V1.3.35.

Versions corrigées :

V1.3.36 et versions ultérieures.

Effectuez une mise à niveau vers la dernière version.

P2

Après la mise à niveau d'une instance Hologres de la version V1.1 vers la version V1.3, l'interrogation ou l'écriture de données Array dans une table partitionnée échoue avec l'erreur : internal error: Datasets has different schema Schema. Ce problème survient lorsqu'une requête accède à des partitions créées avant et après la mise à niveau.

Si un champ de type Array dans la table parente d'une table partitionnée ne possède pas l'attribut not null, la version actuelle gère incorrectement l'attribut nullable. Avant la mise à niveau, le champ est par défaut nullable, mais dans les nouvelles tables de partition enfant créées après la mise à niveau, il est par défaut not null. Lorsqu'une requête touche plusieurs partitions créées avant et après la mise à niveau, une erreur d'exécution se produit en raison de l'incohérence des métadonnées des tables de partition enfant.

Versions concernées :

V1.3.20 à V1.3.35.

Versions corrigées :

V1.3.36 et versions ultérieures.

• Modifiez une propriété de la table partitionnée parente. Exemple :

  CALL set_table_property('table_name', 'time_to_live_in_seconds', 'xx');

• Effectuez une mise à niveau vers la dernière version.

Niveau

Description

Cause

Versions concernées et corrigées

Solutions de contournement

P2

Lorsque le stockage en colonnes JSONB est activé pour une table partitionnée, les requêtes sur la table parente sont lentes, tandis que celles sur ses tables enfants sont rapides.

CREATE TABLE public.hologres_parent(a text, b jsonb) PARTITION BY LIST(a);CREATE TABLE public.hologres_child1 PARTITION OF public.hologres_parent FOR VALUES IN('v1');SELECT b->>'xxx' FROM hologres_parent;

Lorsque le stockage en colonnes JSONB est activé et qu'une table parente est interrogée, l'optimiseur ne parvient pas à propager la requête vers les tables enfants. Cela impose une analyse complète de la colonne JSONB, ce qui dégrade les performances.

Concernées :

Versions 1.3.20 à 1.3.34.

Corrigées :

Version 1.3.35 et versions ultérieures.

• Interrogez directement les tables enfants.

• Effectuez une mise à niveau vers la dernière version.

P2

Lors de l'utilisation du stockage en colonnes JSONB, une requête avec une clause LIMIT est lente car l'optimisation du stockage en colonnes n'est pas appliquée.

create table jsonb_test(inputvalues JSONB );SELECT inputvalues ->> 'price' pos_id FROM jsonb_test where inputvalues ->> 'price' = 'aaa' limit 100;

La présence d'une clause LIMIT empêche la propagation du stockage en colonnes dans le plan d'exécution. Cela impose une analyse complète de la colonne JSONB lors du calcul, ce qui dégrade les performances.

Concernées :

Versions 1.3.20 à 1.3.34.

Corrigées :

Version 1.3.35 et versions ultérieures.

• Évitez d'utiliser une clause LIMIT lorsque le stockage en colonnes JSONB est activé.

• Effectuez une mise à niveau vers la dernière version.

P0

Si une instance avec la lecture directe MC activée redémarre (par exemple, en raison d'un scale-out des nœuds de calcul ou d'une erreur OOM), elle ne parvient pas à démarrer.

Un bug a provoqué une incohérence entre les métadonnées et l'état des données lorsque la lecture directe MC était activée. Cela a empêché le moteur de stockage de charger correctement les données, entraînant l'échec du démarrage. Notez que la correction de ce problème peut entraîner la perte des statuts de suppression.

Concernées :

Versions 1.3.14 à 1.3.33.

Corrigées :

Version 1.3.34 et versions ultérieures.

• N'activez pas la lecture directe MC dans les versions concernées.

• Effectuez une mise à niveau vers la dernière version.

P2

Lors de l'interrogation du Binlog d'une table orientée colonne avec une clé de segment définie, une condition de filtre dans la clause WHERE qui utilise la clé de segment est ignorée.

BEGIN;CREATE TABLE test (  id int PRIMARY KEY,  title text NOT NULL,  c_time timestamptz);CALL set_table_property ('test', 'orientation', 'column');call set_table_property('test', 'event_time_column', 'c_time');call set_table_property('test', 'binlog.level', 'replica');call set_table_property('test', 'binlog.ttl', '86400');COMMIT;SELECT hg_binlog_lsn,hg_binlog_event_type,hg_binlog_timestamp_us,* FROM test where c_time = 1;

Dans cet exemple, la requête renvoie des lignes dont les valeurs c_time sont différentes de 1.

Pour une table orientée colonne configurée avec Binlog et une clé de segment, l'utilisation de la clé de segment dans une clause WHERE générait un plan d'exécution incorrect, rendant le filtre inefficace.

Concernées :

Version 1.3.33 et versions antérieures.

Corrigées :

Version 1.3.34 et versions ultérieures.

Effectuez une mise à niveau vers la dernière version.

P2

L'utilisation de l'opérateur #> pour analyser JSONB renvoie l'erreur suivante : Unicode escape values cannot be used for code point values above 007F when the server encoding is not UTF8. Exemple d'instruction SQL de création de table :

create table t1 (f1 json);insert into t1 values ('{"a":"Hello\u00F7"}');SELECT f1 #> ARRAY['a'] FROM t1;

L'opérateur #> est implémenté avec la fonction json_extract_path, qui utilise par défaut l'encodage ASCII PostgreSQL lors de l'analyse de JSONB. Ce comportement provoque l'erreur.

Concernées :

Version 1.3.33 et versions antérieures.

Corrigées :

Version 1.3.34 et versions ultérieures.

Effectuez une mise à niveau vers la dernière version.

Niveau

Description

Cause

Versions concernées et corrigées

Solution de contournement

P2

Lorsque vous créez une nouvelle base de données avec le modèle d'autorisation SPM, la première consommation d'un Hologres Binlog via JDBC échoue avec l'erreur suivante : ERROR: internal error: create table hologres.hg_replication_progress failed.

Pour consommer un Hologres Binlog via JDBC, le système exécute la commande GRANT SELECT ON TABLE hologres.hg_replication_progress TO PUBLIC; afin d'accorder à tous les utilisateurs l'autorisation de consulter la table hg_replication_progress. Toutefois, le modèle d'autorisation SPM désactive la commande GRANT, ce qui empêche la création de la table et entraîne l'échec de la consommation du Binlog.

Versions concernées :

V1.3.20 à V1.3.32.

Versions corrigées :

V1.3.33 et versions ultérieures.

• Basculez vers le modèle d'autorisation PostgreSQL standard pour accorder les autorisations, puis revenez au modèle d'autorisation SPM pour consommer le Binlog. Vous pouvez également consommer le Binlog directement en utilisant le modèle d'autorisation PostgreSQL standard.

• Effectuez une mise à niveau vers une version corrigée.

P1

Après une mise à niveau vers Hologres V1.3.30, l'utilisation de la mémoire de l'instance augmente de manière inattendue, bien que le QPS et le volume de données restent inchangés.

Hologres dispose par défaut d'un cache de résultats. Si une opération d'insertion dans ce cache échoue, Hologres ne libère pas rapidement les ressources associées, ce qui entraîne une augmentation de l'utilisation de la mémoire.

Versions concernées :

V1.3.30 à V1.3.31.

Versions corrigées :

V1.3.32 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

P2

L'imbrication de la fonction jsonb_array_element au sein de la fonction jsonb_object_field provoque l'erreur suivante : internal error: Only jsonb_object_field and jsonb_object_field_text supported. L'instruction SQL suivante permet de reproduire l'erreur.

create table t1(f1 jsonb);insert into t1 values ('[{"a":1},{"b":2}]');SELECT  f1->0->'a' FROM t1;

Une erreur logique lors de l'imbrication des fonctions entraîne une incompatibilité des valeurs.

Versions concernées :

V1.3.20 à V1.3.29.

Versions corrigées :

V1.3.30 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

P2

Les requêtes exécutées sur une instance secondaire en lecture seule peuvent renvoyer des clés primaires en double, contrairement aux requêtes exécutées sur l'instance principale.

Si des données sont supprimées immédiatement après leur importation, un basculement ultérieur sur l'instance secondaire en lecture seule (déclenché par une mise à niveau ou une mise à l'échelle horizontale) peut empêcher le nettoyage des données comportant des clés primaires en double. Cela conduit les requêtes à renvoyer des clés dupliquées.

Versions concernées :

V1.3.27 à V1.3.28.

Versions corrigées :

V1.3.29 et versions ultérieures.

• Exécutez les requêtes sur l'instance principale.

• Effectuez une mise à niveau vers une version corrigée.

Niveau

Description

Cause

Versions concernées/corrigées

Solution de contournement

P2

Lorsque vous créez une table et définissez un champ nullable comme clé de clustering ou clé de segment, les résultats des requêtes sont parfois incohérents.

Pour les tables dotées d'une clé de clustering ou d'une clé de segment nullable, le cache de résultats stocke incorrectement les résultats des requêtes, ce qui entraîne des incohérences.

Versions concernées :

V1.1.30 à V1.3.27.

Versions corrigées :

V1.3.28 et versions ultérieures.

• Recréez la table et assurez-vous que le champ défini comme clé de clustering ou clé de segment n'est pas nullable.

• Effectuez une mise à niveau vers une version corrigée.

P2

L'utilisation de la fonction ST_Collect(col) provoque l'erreur ERPC_CONNECTION _CLOSED.

Cette erreur survient car Hologres vérifie incorrectement la valeur native PostgreSQL node tag, utilisée pour garantir la compatibilité avec PostGIS.

Versions concernées :

V1.3.27 et versions antérieures.

Versions corrigées :

V1.3.28 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

P2

L'appel de la fonction string_agg(text) provoque l'erreur An I/O error occurred while sending to the backend.

La fonction string_agg est traitée par PQE dans Hologres. Lorsque string_agg(text) est utilisée sans séparateur spécifié, PQE rencontre un pointeur nul, ce qui entraîne une erreur de requête.

Versions concernées :

V1.3.20 à V1.3.27.

Versions corrigées :

V1.3.28 et versions ultérieures.

• Modifiez l'instruction SQL pour spécifier explicitement un séparateur, par exemple string_agg(text, ',').

• Effectuez une mise à niveau vers une version corrigée.

P2

Lors de la lecture des données depuis une table externe MaxCompute, le résultat d'une requête contenant une instruction WITH est incohérent par rapport au résultat d'une requête sans instruction WITH.

Lors de la lecture d'une table étrangère MaxCompute dans un format tel que CFile ou RANGE TABLE, si la requête contient une clause WITH et que l'ordre des colonnes de la sortie de la clause WITH ne correspond pas à l'ordre des colonnes de la table, l'interface de table étrangère Hologres produit les résultats dans le mauvais ordre, ce qui entraîne des incohérences.

Versions concernées :

V1.3.24 à V1.3.26.

Versions corrigées :

V1.3.27 et versions ultérieures.

• N'utilisez pas d'instruction WITH dans la requête.

• Effectuez une mise à niveau vers une version corrigée.

P2

L'interrogation d'un champ de type ARRAY dans une table étrangère MaxCompute provoque l'erreur Array length did not match record batch length.

Lors de l'accès à une table MaxCompute au format ORC, l'interface de table étrangère Hologres gère de manière incohérente la longueur des champs de type ARRAY. Cela peut entraîner un dépassement de la limite de longueur des données, provoquant ainsi une erreur.

Versions concernées :

V1.3.20 à V1.3.26.

Versions corrigées :

V1.3.27 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

Niveau

Description

Cause

Versions concernées/corrigées

Solution de contournement

P2

Si vous définissez la clé de distribution sur une chaîne vide, l'exécution d'une requête échoue avec l'erreur suivante : Failed to get bh reader: internal error CONTEXT. Voici un exemple d'instruction DDL :

call set_table_property('<table_name>', 'distribution_key', ' ');

Lorsque la clé de distribution est une chaîne vide, les données ne peuvent pas être acheminées vers le shard approprié, ce qui provoque une erreur de requête.

Versions concernées :

V1.3.24 et versions antérieures.

Versions corrigées :

V1.3.26 et versions ultérieures.

• Recréez la table et définissez une clé de distribution valide.

• Mettez à jour vers la dernière version.

  Remarque

  Après la mise à jour, la définition d'une clé de distribution sur une chaîne vide n'est toujours pas prise en charge et déclenche une erreur lors de la création de la table.

P2

Lorsque vous interrogez une table externe MaxCompute, l'erreur suivante s'affiche : column with id 0 has type date64[ms] but ReadColumn returns array Array(type=timestamp[ms, tz=UTC].

Hologres convertit incorrectment le type DATETIME lors de la lecture d'une table externe MaxCompute, ce qui entraîne une erreur de requête.

Versions concernées :

De V1.3.20 à V1.3.24.

Versions corrigées :

V1.3.25 et versions ultérieures.

Mettez à jour vers la dernière version.

P2

Après la mise à niveau d'une instance Hologres vers la version V1.3.20, une erreur se produit lors de l'interrogation d'une table externe MaxCompute contenant un champ de type tableau : internal error: IOError: Invalid flatbuffers message.

Une erreur de requête survient car le système utilise une interface de lecture obsolète qui ne reconnaît pas le type tableau.

Versions concernées :

De V1.3.20 à V1.3.24.

Versions corrigées :

V1.3.25 et versions ultérieures.

• Évitez temporairement d'interroger les champs de type tableau.

• Mettez à jour vers la dernière version.

P2

Lorsque vous importez des données depuis une table système PostgreSQL vers une table interne Hologres, les résultats dans la table Hologres sont instables et changent de manière aléatoire. Par exemple :

-- Query result is 22505
SELECTcount(1)FROMpg_class c inner join pg_attribute a on c.oid = a.attrelid
-- Create an internal table
CREATE TABLE public. tables11 (schemaname name NULL);
truncate public. tables11
-- Inserted data changes randomly
insert into public.tables11
SELECT'tmp'FROMpg_class c inner join pg_attribute a on c.oid = a.attrelid
SELECT count(1) FROM public.tables11

Les tables système PostgreSQL sont des objets natifs PostgreSQL. Hologres étant un système distribué, des opérations DDL continues peuvent entraîner des décalages de version entre les nœuds FE (Frontend). L'interrogation des tables système PostgreSQL peut récupérer des données provenant de différents nœuds FE, ce qui conduit à des résultats instables.

Versions concernées :

De V1.3.22 à V1.3.24.

Versions corrigées :

V1.3.25 et versions ultérieures.

Mettez à jour vers la dernière version.

P2

Après la mise à niveau d'une instance Hologres vers la version V1.3.20 ou ultérieure, les requêtes contenant des champs DECIMAL dans une instruction case when peuvent échouer avec l'erreur suivante : internal error: column with id 0 has type decimal(38, 3) but ReadColumn returns array Array(type=decimal(38, 10) length=3 null_count=0.

Dans une instruction case when, la précision du type DECIMAL n'est pas explicitement convertie. L'optimiseur déduit incorrectement la précision lors de la génération du plan d'exécution, ce qui entraîne l'échec de la requête.

Versions concernées :

De V1.3.20 à V1.3.24.

Versions corrigées :

V1.3.24 et versions ultérieures.

Mettez à jour vers la dernière version.

P2

Lorsque vous importez des données depuis une vue système PostgreSQL vers une table Hologres créée par l'utilisateur, aucune donnée n'est insérée. Exemple SQL :

CREATE table holo_pg_tables (schemaname text,tablename text,tableowner text,tablespace text,hasindexes text,hasrules text,hastriggers text,rowsecurity text);
insert into holo_pg_tables SELECT * FROM pg_catalog.pg_tables;

La vue système PostgreSQL pg_catalog.pg_tables inclut la condition de filtre c.relkind = ANY (ARRAY['r'::"char", 'p'::"char"]). Lors de la génération du plan d'exécution, ce type est incorrectement converti en une valeur sans signification, de sorte qu'aucune ligne ne correspond au filtre.

Versions concernées :

De V1.3.22 à V1.3.24.

Versions corrigées :

V1.3.25 et versions ultérieures.

Mettez à jour vers la dernière version.

P2

La configuration de deux index vectoriels Proxima sur une table peut dégrader les performances des requêtes vectorielles Proxima par rapport à la configuration d'un seul index. Exemple DDL :

call set_table_property('t1', 'proxima_vectors', '{"f2":{"algorithm":"Graph","distance_method":"InnerProduct"}},{"f3":{"algorithm":"Graph","distance_method":"InnerProduct"}}');

Lorsque vous définissez deux index, la syntaxe du bloc {} dans l'instruction DDL est incorrecte. Chaque index doit posséder son propre bloc {}. Le nœud FE n'a pas rejeté l'instruction DDL avec ce format. Par conséquent, le premier index a été créé avec succès, mais le second a été ignoré, ce qui a entraîné une baisse des performances des requêtes. Le format correct est le suivant :

call set_table_property('t1', 'proxima_vectors', '{"f2":{"algorithm":"Graph","distance_method":"InnerProduct"},"f3":{"algorithm":"Graph","distance_method":"InnerProduct"}}');

Versions concernées :

V1.3.24 et versions antérieures.

Versions corrigées :

V1.3.25 et versions ultérieures.

• Recréez la table et utilisez la syntaxe DDL correcte pour définir les index.

• Mettez à jour vers la dernière version.

  Remarque

  Après la mise à jour, cette syntaxe incorrecte n'est toujours pas prise en charge, mais elle déclenchera une erreur lors de la création de la table.

P2

Lorsqu'un utilisateur non superutilisateur exécute la commande SELECT hg_dump_script('xxxx'), l'erreur suivante s'affiche : ERROR: permission denied for table pg_subscription.

La fonction hg_dump_script appelle indirectement pg_subscription pour la réplication logique. L'erreur survient car la vérification des autorisations pour pg_subscription échoue.

Versions concernées :

De V1.3.20 à V1.3.24.

Versions corrigées :

V1.3.25 et versions ultérieures.

• Utilisez un compte superutilisateur pour accorder les autorisations. Exemple de commande :

  GRANT SELECT ON pg_subscription TO "xx";

• Mettez à jour vers la dernière version.

P2

Un utilisateur RAM reçoit l'erreur NoSuchProject lorsqu'il utilise Flink pour consommer un journal binlog Hologres ou DataHub pour écrire des données dans Hologres.

L'erreur survient car le frontend analyse incorrectement l'utilisateur RAM.

Versions concernées :

V1.3.23 et versions antérieures.

Versions corrigées :

V1.3.24 et versions ultérieures.

Mettez à jour vers la dernière version.

P2

Après la mise à niveau d'une instance Hologres de la version V1.1 vers la version V1.3, les requêtes adressées aux tables externes MaxCompute peuvent prendre plus de temps. Lorsque vous consultez le plan d'exécution en exécutant EXPLAIN, le champ row_count dans les statistiques de la table affiche 1000. Cela indique que les statistiques de la table ne sont pas automatiquement mises à jour.

Après la mise à niveau d'une instance Hologres vers la version V1.3, Auto Analyze ne détecte pas le schéma de la table externe. Par conséquent, les statistiques de la table externe ne sont pas collectées rapidement.

Versions concernées :

De V1.3.14 à V1.3.23.

Versions corrigées :

V1.3.24 et versions ultérieures.

• Exécutez manuellement la commande ANALYZE <tablename>.

• Mettez à jour vers la dernière version.

P2

Les requêtes utilisant UNION ALL avec des champs DECIMAL peuvent échouer avec l'erreur suivante : Schema fields[4] has type decimal(14, 4) but decimal(11, 2) is expected.

CREATE TABLE t1(n decimal(6,4));
CREATE TABLE t2(n decimal(5,3));
SELECT * FROM (SELECT 1 as type, n FROM t1 UNION ALL SELECT 2 as type, n FROM t2)t where t.type=2;

Lors de la génération du plan d'exécution pour une opération UNION ALL, la précision du type DECIMAL est incorrectement tronquée, ce qui entraîne une incompatibilité de précision.

Versions concernées :

De V1.3.20 à V1.3.23.

Versions corrigées :

V1.3.24 et versions ultérieures.

Mettez à jour vers la dernière version.

Niveau

Description

Cause

Versions concernées/corrigées

Solutions de contournement

P2

Le schéma spécifié dans une chaîne de connexion JDBC n'est pas appliqué et la valeur par défaut est le schéma public. Voici un exemple de chaîne de connexion :

String jdbcUrl = "jdbc:postgresql://hostname: port /dbname?currentSchema=demo;

Le nœud FE ignore la chaîne située après le point d'interrogation (?) dans la chaîne de connexion, ce qui entraîne l'ignorance du paramètre currentSchema.

Versions concernées :

V1.3.14 à V1.3.22.

Versions corrigées :

V1.3.23 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

P1

Une instance redémarre brièvement lorsqu'une requête SQL est automatiquement réécrite pour utiliser une vue matérialisée.

Lors de la génération d'un plan d'exécution pour une requête réécrite afin d'utiliser une vue matérialisée, l'optimiseur ne parvient pas à récupérer les métadonnées de la table, ce qui provoque une défaillance de l'instance.

Versions concernées :

V1.3.14 à V1.3.22.

Versions corrigées :

V1.3.23 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

P2

Si vous configurez des politiques de liste d'autorisation IP différentes pour différents utilisateurs au sein d'une instance, les utilisateurs ne peuvent pas accéder à l'instance Hologres, même depuis des adresses IP figurant dans la liste d'autorisation. L'erreur reject ip xxx est alors renvoyée.

La passerelle bloque incorrectement l'utilisateur après la configuration d'une liste d'autorisation IP. Cela empêche l'utilisateur d'accéder à l'instance, bien qu'il figure sur la liste d'autorisation.

Versions concernées :

V1.3.21 et versions antérieures.

Versions corrigées :

V1.3.22 et versions ultérieures.

• Ne configurez pas de liste d'autorisation IP ou modifiez la politique utilisateur pour la liste d'autorisation en définissant le paramètre Accessible Databases sur ALL.

• Effectuez une mise à niveau vers une version corrigée.

P2

Dans un scénario de requête ponctuelle utilisant un Fixed Plan, l'interrogation de données Decimal renvoie le message d'erreur suivant : get result failed:scale should between xxxx. Voici un exemple :

begin;create table t (k1 int, k2 decimal(18, 2), primary key(k1, k2));call set_table_property ('t', 'distribution_key', 'k1');end;insert into t (1, 12,11);set hg_experimental_enable_fixed_dispatcher_for_scan = on;SELECT * FROM t where k1=1 and k2>10,1 and k2 < 12,3;

Dans un scénario Fixed Plan, l'optimiseur déduit incorrectement la précision du type Decimal, ce qui provoque l'erreur.

Versions concernées :

V1.3.20 et versions antérieures.

Versions corrigées :

V1.3.21 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

P2

Après l'activation d'une liste d'autorisation IP, un job Flink consommant le Binlog Hologres échoue avec l'erreur suivante : reject ip 1.xxx.

Flink consomme le Binlog Hologres via l'interface d'importation de données en temps réel Hologres (mode non JDBC), qui ne prend pas en charge la fonctionnalité de liste d'autorisation IP.

Versions concernées :

V1.3.20 et versions antérieures.

Versions corrigées :

V1.3.21 et versions ultérieures.

• Ne configurez pas de liste d'autorisation IP.

• Effectuez une mise à niveau vers une version corrigée.

P2

Lorsque vous convertissez explicitement un type tableau en type chaîne, l'erreur suivante se produit : ERROR: Cast FROM LIST to STRING is not supported.. Par exemple :

create table aaa1(a text[],b int[]);insert into aaa1 values (ARRAY['1','aaa'], ARRAY[1,2,3]);d=# SELECT a::text, b::text FROM aaa1;

Hologres ne prend pas en charge la conversion explicite d'un type tableau en type chaîne.

Versions concernées :

V1.3.20 et versions antérieures.

Versions corrigées :

V1.3.21 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.

P1

Lorsque vous interrogez une table externe MaxCompute, la requête se bloque. Le redémarrage de l'instance résout le problème.

Lors de la lecture des métadonnées pendant un basculement primaire/secondaire dans le service de métadonnées MaxCompute, Hologres ne parvient pas à gérer l'exception. Cela entraîne l'échec des tentatives et le blocage de la requête.

Versions concernées :

V1.3.20 et versions antérieures.

Versions corrigées :

V1.3.21 et versions ultérieures.

Effectuez une mise à niveau vers une version corrigée.