Migration vers 9.4 et supérieures¶

Configuration¶

L’authentification krb5 était dépréciée depuis plusieurs années et n’est maintenant plus supportée. Elle est remplacée par GSSAPI.

`pg_upgrade`¶

Les options de la commande pg_upgrade ont été modifiées pour être cohérentes avec tous les autres outils clients et serveurs de PostgreSQL. L’option -u devient maintenant -U, elle permet de définir le superutilisateur de l’instance.

Si la commande est invoquée avec l’option -u, elle retournera une erreur :

$ /usr/pgsql-9.4/bin/pg_upgrade --old-datadir=/var/lib/pgsql/9.2/data --new-datadir=/var/lib/pgsql/9.4/data --old-bindir=/usr/pgsql-9.2/bin --new-bindir=/usr/pgsql-9.4/bin -u postgres
pg_upgrade: invalid option -- 'u'

Try "pg_upgrade --help" for more information.
Failure, exiting

La commande pg_upgrade devra donc être invoquée en modifiant l’option -u en -U :

$ /usr/pgsql-9.4/bin/pg_upgrade --old-datadir=/var/lib/pgsql/9.2/data --new-datadir=/var/lib/pgsql/9.4/data --old-bindir=/usr/pgsql-9.2/bin --new-bindir=/usr/pgsql-9.4/bin -U postgres

Changement de définition de vues systèmes¶

Les vues systèmes pg_stat_activity, pg_stat_replication et pg_stat_all_tables ont été modifiées et proposent des colonnes supplémentaires.

La vue pg_stat_activity s’est vue ajouter deux colonnes supplémentaires :

backend_xid, de type xid, qui indique l’identifiant de transaction en cours d’une session donnée ;
backend_xmin, de type xid, qui indique le snapshot minimal vu par la session.

La colonne backend_xid est renseignée seulement si une transaction en écriture est en cours, sinon elle vaut NULL. La colonne backend_xmin est renseignée seulement si une requête de lecture est en cours d’exécution, sinon elle vaut NULL.

La vue pg_stat_replication s’est également vue ajouter une colonne supplémentaire :

backend_xmin, de type xid.

Cette colonne indique l’identifiant de transaction le plus ancien vu par le serveur secondaire connecté.

Les quatre colonnes sent_location, write_location, flush_location et replay_location sont également modifiées dans pg_stat_replication. Leur type passe de texte à pg_lsn, qui est un nouveau type en version 9.4, permettant de les manipuler avec les nouveaux opérateurs disponibles.

Enfin, la vue pg_stat_all_tables voit également l’apparition d’une nouvelle colonne :

n_mod_since_analyze, de type bigint.

Cette colonne indique le nombre estimé de lignes modifiées depuis le dernier ANALYZE sur cette table.

Contraintes `CHECK` et colonnes systèmes¶

Les contraintes CHECK ne sont plus autorisées à utiliser les colonnes systèmes, excepté tableoid. Il n’y avait aucun cas d’usage réellement pertinent pour de telles contraintes, qui de toute manière n’induisait que des erreurs systématiques.

`DISCARD ALL` et séquences¶

L’ordre DISCARD ALL, utilisé par les pooleurs de connexions pour réinitialiser l’état d’une session, ne réinitialisait pas l’état des séquences. Avec la version 9.4, l’état des séquences est maintenant réinitialisé par DISCARD ALL.

Jusqu’à PostgreSQL 9.3, DISCARD ALL n’affectait pas l’état des séquences :

postgres=# CREATE SEQUENCE seq;
CREATE SEQUENCE
postgres=# SELECT currval('seq');
ERROR:  currval of sequence "seq" is not yet defined in this session
postgres=# SELECT nextval('seq');
 nextval 
---------
       1
(1 ligne)

postgres=# SELECT currval('seq');
 currval 
---------
       1
(1 ligne)

postgres=# DISCARD ALL;
DISCARD ALL
postgres=# SELECT currval('seq');
 currval 
---------
       1
(1 ligne)

À partir de PostgreSQL 9.4, il n’est plus possible de connaître l’état d’une séquence après DISCARD ALL :

postgres=# CREATE SEQUENCE seq;
CREATE SEQUENCE
postgres=# SELECT currval('seq');
ERROR:  currval of sequence "seq" is not yet defined in this session
postgres=# SELECT nextval('seq');
 nextval 
---------
       1
(1 ligne)

postgres=# SELECT currval('seq');
 currval 
---------
       1
(1 ligne)

postgres=# DISCARD ALL;
DISCARD ALL
postgres=# SELECT currval('seq');
ERROR:  currval of sequence "seq" is not yet defined in this session

Si une application s’appuie sur ce principe, il s’agit d’un bug de l’application qui doit être corrigé.

Changement sur les `ARRAY`¶

Le parseur de tableau est maintenant plus strict, en particulier sur les données de types tableaux à plusieurs dimensions qui n’étaient pas gérés correctement lorsque certains éléments n’étaient pas renseignés.

Ainsi, avec PostgreSQL 9.3, une telle entrée était possible, le premier élément se retrouvant adjoint d’une valeur NULL implicite :

postgres=# SELECT '{{1}, {2,3}}'::int[];
       int4       
------------------
 {{1,NULL},{2,3}}
(1 ligne)

Avec PostgreSQL 9.4, une telle entrée génère une erreur :

postgres=# SELECT '{{1}, {2,3}}'::int[];
ERROR:  malformed array literal: "{{1}, {2,3}}"
LINE 1 : SELECT '{{1}, {2,3}}'::int[];
                 ^
DETAIL : Multidimensional arrays must have sub-arrays with matching dimensions.

Les tableaux d’entiers vides sont désormais réellement des tableaux vides, comme pour les autres types de données.

Changement sur `JSON`¶

La représentation des données JSON a été modifiée, en particulier la date. Auparavant, les dates étaient affichées selon le paramètre de session DateStyle. Dorénavant, elles sont affichées selon la norme ISO 8601, car de nombreux parseurs automatisés s’attendent à trouver ce format normalisé.

De même, les chaînes d’échappement Unicode ne sont plus rendues en protégeant les anti-slashs par des échappements. Cela pouvait entraîner des comportements inattendus.

Nouvelle API pour les background workers¶

L’API pour les background workers a évolué et des changements incompatibles avec l’API de PostgreSQL 9.3 ont été introduits. Il faudra faire évoluer le code des backgrounds workers pour le rendre compatible.

Modification comportement de `SET LOCAL/CONSTRAINTS/TRANSACTION` et `ROLLBACK/ABORT`¶

Avant la version 9.4, l’utilisation de SET LOCAL/CONSTRAINTS/TRANSACTION en dehors d’une transaction ne faisait rien, mais n’affichait pas de warning, maintenant cela ne fait toujours rien, mais affiche un warning. C’est en tous les cas révélateur d’une utilisation erronée de SET LOCAL/CONSTRAINTS/TRANSACTION qui en 9.3 et avant pouvait vous faire penser que le SET était correctement positionné.

Pour illustrer le problème du warning, en 9.3 :

postgres=# SET LOCAL search_path = 'test,public';
SET
postgres=# show search_path ;
  search_path   
----------------
 "$user",public
(1 row)

postgres=# BEGIN;
BEGIN
postgres=# SET LOCAL search_path = 'test,public';
SET
postgres=# show search_path ;
  search_path  
---------------
 "test,public"
(1 row)

postgres=# ROLLBACK;
ROLLBACK

et en version supérieure ou égale à 9.4 :

postgres=# SET LOCAL search_path = 'test,public';
WARNING:  SET LOCAL can only be used in transaction blocks
SET
postgres=# show search_path ;
   search_path   
-----------------
 "$user", public
(1 ligne)

postgres=# BEGIN;
WARNING:  there is already a transaction in progress
BEGIN
postgres=# SET LOCAL search_path = 'test,public';
SET
postgres=# show search_path ;
  search_path  
---------------
 "test,public"
(1 ligne)

postgres=# ROLLBACK;
ROLLBACK

De même pour l’appel à ROLLBACK ou ABORT :

postgres=# ROLLBACK;
ROLLBACK
postgres=# SET client_min_messages TO notice;
SET
postgres=# ROLLBACK;
NOTICE:  there is no transaction in progress
ROLLBACK

En version 9.4 et supérieure :

postgres=# ROLLBACK;
WARNING:  there is no transaction in progress
ROLLBACK
postgres=# ABORT;
WARNING:  there is no transaction in progress
ROLLBACK

Migration vers 9.4 et supérieures¶

Configuration¶

pg_upgrade¶

Changement de définition de vues systèmes¶

Contraintes CHECK et colonnes systèmes¶

DISCARD ALL et séquences¶

Changement sur les ARRAY¶

Changement sur JSON¶