Cet article est le résultat d’une revue de code demandée par l’un de nos clients.

Notre client a exécuté la commande pg_dump --schema-only pour nous fournir
les définitions des objets de niveau database ainsi que le code PLpgsql à auditer.
Jusque là, tout allait bien.

J’ai commencé à lire le code et tout d’un coup je fus pris d’un doute, vous savez
le méchant doute qui vous donne l’impression que votre château de cartes va s’écrouler.
Voici la fonction que j’avais sous les yeux:

CREATE FUNCTION xxx( p_id character, p_info character varying )
RETURNS integer
LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
   ...
   INSERT INTO t1
   SELECT * FROM t2 WHERE t2.id = p_id;
   ...
END;
$$
;

Peut-être que la première lecture de la fonction ne vous a pas choqué.
Et si je vous disais que la définition de la table t2 ressemble à ce qui suit:

CREATE TABLE t2 (
   id VARCHAR(130) NOT NULL
   ...
   PRIMARY KEY (id)
);

En pratique t2.id est toujours une chaîne de 130 caractères et il y a 400
millions de tuples dans cette table. Comme vous l’avez déjà probablement compris,
il semble étonnant d’avoir p_id CHARACTER pour manipuler id VARCHAR(130). Pour
mémoire, CHARACTER est l’alias de CHAR(1).

Notre client utilise cette fonction depuis plusieurs années et il n’a pas eu de
problème avec ce code. Néanmoins, notre client m’a dit que la définition de cette
fonction ne correspond pas à ce qu’il a écrit: c’était p_id CHARACTER(130) et
non CHARACTER.

Mais que s’est-il donc passé ? Attaquons la pelotte de laine et voyons si Ariane
nous est d’un grand secours.

CREATE FUNCTION test( c character, d character varying )
RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
  RAISE NOTICE 'c=%, d=%', c,d;
END;
$$;

SELECT test( '123465789', '987654321' );
NOTICE:  c=123465789, d=987654321
 test 
------
 
(1 row)

Voilà un résultat bien intéressant: la chaîne ‘123456789’ n’a pas été réduite à
‘1’ (pas de CAST CHAR(1)). Augmentons le niveau de détails:

EXPLAIN (COSTS OFF,ANALYZE,VERBOSE)
        SELECT test( '123465789', '987654321' );
NOTICE:  c=123465789, d=987654321
                             QUERY PLAN                              
---------------------------------------------------------------------
 Result (actual time=0.040..0.041 rows=1 loops=1)
   Output: test('123465789'::bpchar, '987654321'::character varying)
 Planning Time: 0.023 ms
 Execution Time: 0.053 ms
(4 rows)

Nous observons un CAST vers bpchar. Pour mémoire, BPCHAR représente une
chaîne pouvant contenir 10 485 760 caractères. Il est aussi un alias de
CHARACTER ce qui explique partiellement le passage de CHARACTER à BPCHAR.

Explorons une autre facette du problème:

CREATE FUNCTION test(c character(4))
RETURNS character(4)
LANGUAGE sql
AS $$
select c;
$$;

Nous avons changé le langage de la fonction pour savoir si le comportement observé
est propre à PLpgsql. Les données en entrée et en sortie sont de type CHAR(4).
Comment cela va-t-il se comporter ?

SELECT test('123456789');
   test    
-----------
 123456789
(1 row)

EXPLAIN VERBOSE SELECT test('123456789');
                QUERY PLAN                 
-------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=32)
   Output: '123456789'::bpchar
(2 rows)

La bonne nouvelle (si si) c’est que le comportement observé est le même dans
les deux contextes. En revanche, alors que l’on s’attend à manipuler des données
de type CHAR(4), la fonction manipule des données de taille arbitraire (limitée
à ~10M caractères) !!

Cependant, ne vous précipitez pas dans la mailing list de PostgreSQL pour vous plaindre !

En fait, ce comportement n’est pas un bug. La documentation affirme:

“The full SQL type syntax is allowed for declaring a function’s arguments and return value. However, parenthesized type modifiers (e.g., the precision field for type numeric) are discarded by CREATE FUNCTION. Thus for example CREATE FUNCTION foo (varchar(10)) … is exactly the same as CREATE FUNCTION foo (varchar) …”

Ceci explique que CHARACTER(x) devient CHARACTER transformé (par aliasing)
en BPCHAR qui n’est pas CHAR(1) mais plutôt VARCHAR(10485760). Le
comportement est maintenant complétement expliqué.

Attendez une seconde ! L’intention était de traiter des données CHAR(4) pas
de taille différente.

N’y a-t-il pas de solution ? Non, désolé… (à mois que…)

Plus loin dans la page de la documentation référencée ci-dessus, on peut lire
que argtype et rettype peuvent être de type base, composite, domain
ou même du type d’une table/colonne.

L’astuce est de créer un type composite ou un domain a utiliser en tant que
argtype et/ou rettype.

Voici quelques exemples:

-- Works in simple case trick
SELECT test( '12345789'::char(4) );

-- Domain trick
CREATE DOMAIN c4 AS char(4);
CREATE FUNCTION test(param c4)
RETURNS c4
AS $$
BEGIN
  RAISE NOTICE 'param=%', param;
  RETURN param;
END;
$$ LANGUAGE plpgsql;

SELECT test( '123456789' );
ERROR:  value too long for type character(4)

SELECT test( '123456789'::char(4) );
NOTICE:  param=1234
 test 
------
 1234
(1 row)

SELECT test( '123456789'::c4);
NOTICE:  param=1234
 test 
------
 1234
(1 row)

SELECT pg_typeof( test( '123456789'::char(4) ) );
NOTICE:  param=1234
 pg_typeof 
-----------
 c4
(1 row)

Le résultat obtenu devrait vous satisfaire.

Vous n’êtes pas satisfait ?

Je vous propose une dernière astuce.

-- Map a table structure
CREATE TABLE qq ( c char(4));

CREATE FUNCTION test(IN c qq, OUT d qq)
LANGUAGE sql
AS $$
SELECT c;
$$;

SELECT * FROM test(ROW('12345'));
ERROR:  value too long for type character(4)

SELECT * from test(ROW('1234'));
  c   
------
 1234

Hmm, d’accord mais en quoi est-ce différent de l’utilisation d’un domain ?

-- Easy Type Alteration
ALTER TABLE qq ALTER c TYPE char(5);

SELECT * FROM test( ROW('12345') );
   c   
-------
 12345

Essayer de modifier un domain, vous verrez comme c’est simple et pas impactant (…).

L’astuce basée sur la définition de table permet de la flexibilité:

ALTER TABLE qq ADD ee int;

SELECT test( ROW('12345', 4) );
   test   
----------
 (12345,4)

SELECT * FROM test( ROW('12345', 4) );
   c   | ee 
-------+----
 12345 |  4

Nous espérons que vous avez apprécié cet article et que vous avez appris quelque chose de nouveau et d’intéressant.

Tout d’abord, la documentation

L’annexe K de la documentation PostgreSQL indique qu’une table peut contenir jusqu’à 1 600 colonnes.

Il s’agit d’une limite codée en dur, visible dans le code source à l’adresse src/include/access/htup_details.h :

#define MaxTupleAttributeNumber 1664
#define MaxHeapAttributeNumber	1600

Atteindre la limite de manière classique

Vérifions d’abord cette affirmation par quelques tests.

Jouer avec la définition de la table

Nous utilisons ici un script bash simple, facile à adapter aux différents tests.

-- Exemple classique

DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tint_1601;';
    EXECUTE 'CREATE TABLE tint_1601(i_1 int);';
    FOR i IN 2..1601 LOOP
        EXECUTE format('ALTER TABLE tint_1601 ADD COLUMN i_%s int;', i);
    END LOOP;
END $$;

Le résultat est le suivant :

NOTICE:  table "tint_1600" does not exist, skipping
ERROR:  tables can have at most 1600 columns
CONTEXT:  SQL statement "ALTER TABLE tint_1600 ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTE

Jusqu’ici, tout va bien (ou du moins, tout fonctionne comme prévu).

Vous pourriez tenter de remplacer le type int4 par le type int2 pour arriver à créer une table de plus de 1 600 colonnes. Mais cela ne fonctionnera pas plus, car il s’agit d’une limite codée en dur.

Jouer avec le contenu d’une table

Générons une table de 1600 colonnes à partir du script sql précédent :

DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
    EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
    FOR i IN 2..1600 LOOP
        EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN i_%s int;', i);
    END LOOP;
END $$;

Construisons puis insérons un tuple de 1600 colonnes :

DO $$
DECLARE
    s TEXT;
    rows_inserted int;
BEGIN
    s := format(
                 'INSERT INTO tint_1600 VALUES (1%s);'
               , repeat( ',1' , 1599 )
               );
    EXECUTE s;

    GET DIAGNOSTICS rows_inserted = ROW_COUNT;
    RAISE NOTICE 'Rows inserted: %', rows_inserted;
END $$;

The output is:

NOTICE:  Rows inserted: 1
DO

Sans surprise, c’est encore un succès.

Trop gros pour échouer ?

Continuons à repousser les limites.

On créé maintenant une autre table de 1 600 colonnes, cette fois avec le type de données char(127).

On réutilise notre script bash avec quelques modifications :

-- Create a table with 1,600 columns: 1 x int + 1599 x char(127)
DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
    EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
    FOR i IN 2..1600 LOOP
        EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN c_%s char(127) NOT NULL;', i);
    END LOOP;
END $$;

-- Insert a tuple - 1 x int + 1599 x char(127)
DO $$
DECLARE
    s TEXT;
BEGIN
    s := format(
                 'INSERT INTO tint_1600 VALUES (1%s);'
               , repeat( $q$,'1'::char(127)$q$ , 1599 )
               );
    EXECUTE s;
END $$;```

Le résultat est :

ERROR: row is too big: size 25616, maximum size 8160

Comme on peut le voir, la table comporte effectivement 1 600 colonnes, mais cette fois, le tuple ne peut pas tenir dans une seule page heap, ce qui explique l'erreur « row is too big: size 25616, maximum size 8160 ». Si vous avez fait attention au script, vous avez pu constater que les colonnes sont définies comme `NOT NULL`. Aussi, lors de la création de la table, PostgreSQL aurait pu se rendre compte que l'insertion de données serait impossible. Mais il n'y a pas eu d'alerte.

## Quid des JOINs ?

Pour simplifier, testons avec une jointure automatique :

```sql
SELECT a.*,b.* FROM tint_1600 a, tint_1600 b;
ERROR:  target lists can have at most 1664 entries

Maintenant, c’est la clause SELECT de (a.*,b.*) qui a atteint sa propre limite (MaxTupleAttributeNumber = 1664).

Atteindre la limite de colonnes de manière inattendue

Il arrive que vous deviez modifier votre application, et que cela entraîne des modifications de schéma.
La plupart du temps, il s’agit de modifications de tables, comme l’ajout ou la suppression de colonnes.

Explorer ADD / DROP COLUMN

Voyons ce qui se passe côté SQL lorsque nous ajoutons, puis supprimons, une colonne.

=# CREATE TABLE tadc_1600(i_1 int NOT NULL);

CREATE TABLE

=# ALTER TABLE tadc_1600 ADD COLUMN i_2 int NOT NULL;

ALTER TABLE

=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
   FROM pg_attribute
   WHERE attrelid=(
                   SELECT oid
                   FROM pg_class
                   WHERE relname='tadc_1600'
                   )
     AND attnum > 0 ORDER BY attnum;

 attname | attnum | attstorage | attnotnull | attisdropped
---------+--------+------------+------------+--------------
 i_1     |      1 | p          | t          | f
 i_2     |      2 | p          | t          | f
(2 rows)

=# ALTER TABLE tadc_1600 DROP COLUMN i_2;

ALTER TABLE

=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
   FROM pg_attribute
   WHERE attrelid=(
                   SELECT oid
                   FROM pg_class
                   WHERE relname='tadc_1600'
                   )
     AND attnum > 0 ORDER BY attnum;

           attname            | attnum | attstorage | attnotnull | attisdropped
------------------------------+--------+------------+------------+--------------
 i_1                          |      1 | p          | t          | f
 ........pg.dropped.2........ |      2 | p          | f          | t
(2 rows)

Lors de la suppression d’une colonne, cette colonne

• est renommée en « . » + « pg.dropped.» + attnum + « . »,
• devient NULLable,
• est marquée comme supprimée.

Itérer sur l’ajout/la suppression de colonnes

On peut se demander s’il existe une limite au nombre d’opérations d’ajout/suppression qui peuvent être exécutées sur une table donnée.

Comme d’habitude, testons :

-- ADD / DROP COLUMN example
DO $$
DECLARE
    i int;
BEGIN
    EXECUTE 'DROP TABLE IF EXISTS tadc;';
    EXECUTE 'CREATE TABLE tadc(i_1 int);';
    FOR i IN 2..1601 LOOP
        EXECUTE format('ALTER TABLE tadc ADD COLUMN i_%s int;', i);
        EXECUTE format('ALTER TABLE tadc DROP COLUMN i_%s;', i);
    END LOOP;
END $$;

Le résultat est :

ERROR:  tables can have at most 1600 columns
CONTEXT:  SQL statement "ALTER TABLE tadc ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTE

Oh oh ! On a atteint la limite des 1 600 ici aussi !

Explorons un peu ce qui se passe :

=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
   FROM pg_attribute
   WHERE attrelid=(
                   SELECT oid
                   FROM pg_class
                   WHERE relname='tadc'
                   )
     AND attnum > 0 ORDER BY attnum;

             attname             | attnum | attstorage | attnotnull | attisdropped
---------------------------------+--------+------------+------------+--------------
 i_1                             |      1 | p          | t          | f
 ........pg.dropped.2........    |      2 | p          | f          | t
 ........pg.dropped.3........    |      3 | p          | f          | t
 ........pg.dropped.4........    |      4 | p          | f          | t
 ........pg.dropped.5........    |      5 | p          | f          | t

 ........pg.dropped.1599........ |   1599 | p          | f          | t
 ........pg.dropped.1600........ |   1600 | p          | f          | t
(1600 rows)

La table tadc comporte 1 600 colonnes. Vous pouvez vous en apercevoir car toutes les modifications sont ajoutées à la table, et son contenu n’est pas réécrit.

Aussi, à ce stade, toute modification supplémentaire visant à ajouter ou supprimer des colonnes sera vouée à l’échec.

Comment faire pour me sortir de cette situation ?

Le chevalier du VACUUM devrait sauver la princesse PostgreSQL, non ?

Et non ! La commande VACUUM fonctionne au niveau du tuple, donc même si vous exécutez un VACUUM FULL, la structure de la table ne changera pas.

Donc le dragon a mangé le chevalier, que fait-on ?

Il ne s’agit pas d’un problème de tuples morts, mais plutôt d’un problème de catalogue.
Vous devez créer une nouvelle définition de table.

Voici quelques solutions, des plus simples aux plus complexes :

1. Créer une nouvelle table avec interruption de service

   • CREATE TABLE LIKE (INCLUDING ALL)
   • Copier (COPY) les données de l’ancienne table vers la nouvelle
   • Renommer les tables
   • Supprimer l’ancienne table

2. Exploiter la réplication logique pour minimiser les interruptions de service

   • CREATE TABLE LIKE (INCLUDING ALL)
   • CREATE local PUBLICATION/SUBSCRIPTION
   • Une fois les données synchronisées, arrêter/mettre en pause le service applicatif
   • Supprimer l’abonnement
   • Renommer les tables
   • Redémarrer/relancer l’application
   • Supprimer l’ancienne table

Contactez-nous

Vous avez d’autres idées pour résoudre ce problème ? Vous avez trouvé d’autres moyens étranges de déclencher cette erreur liée à la limite codée en dur ? Contactez-nous ! Nous sommes toujours ravis d’échanger sur PostgreSQL.