Aller au contenu

Migration vers 9.2 et supérieures

pg_stat_activity

La vue pg_stat_activity change. Jusqu’en 9.1, le seul moyen de savoir si une connexion était inactive, il fallait comparer le champ current_query à <IDLE> et <IDLE> in transaction. Dorénavant, le champ state fournit l’information sur l’activité du processus serveur. Il peut avoir les valeurs suivantes :

  • active ;
  • idle ;
  • idle in transaction ;
  • idle in transaction (aborted) ;
  • fastpath function call ;
  • disabled.

Une requête est en cours uniquement si le champ state vaut active. Ainsi donc, le champ current_query a également été modifié. Si le champ state vaut active, il contient la requête en cours d’exécution, sinon il contient la dernière requête à avoir été exécutée par le processus serveur.

De plus, le champ procpid a été renommé en pid pour plus de cohérence avec les autres vues, notamment pg_locks.

pg_stat_replication

Le champ procpid de la vue pg_stat_replication a également été renommé en pid.

pg_tablespace

La table pg_tablespace perd son champ spclocation. À la place, il faut utiliser pg_tablespace_location() pour obtenir le chemin d’accès au tablespace. Cela permet de pouvoir déplacer un tablespace alors que la base est arrêtée.

Disparition de l’opérateur => pour les hstore

Signalé en warning depuis la version 9.0, l’opérateur => (utilisé pour définir un hstore) disparait. À la place, il faut utiliser la fonction hstore(text,text) :

postgres=# SELECT 'a'=>'1';
ERROR:  operator does NOT exist: UNKNOWN => UNKNOWN
LIGNE 1 : SELECT 'a'=>'1';

postgres=# SELECT hstore('a','1');
-[ RECORD 1 ]----
hstore | "a"=>"1"

Fichier postgresql.conf

Plusieurs options de configuration disparaissent :

  • silent_mode. Utiliser à la place pg_ctl -l postmaster.log ;
  • wal_sender_delay, inutile depuis l’arrivée des latches en 9.2 ;
  • custom_variable_classes. Il est maintenant inutile de déclarer une classe pour pouvoir l’utiliser.

Il est maintenant possible de définir les emplacements des fichiers SSL avec les nouvelles options de configuration suivante:

  • ssl_ca_file ;
  • ssl_cert_file ;
  • ssl_crl_file ;
  • ssl_key_file.

Le paramètre timezone change de comportement en version 9.2. S’il n’est pas spécifié, PostgreSQL utilisera le fuseau horaire GMT comme fuseau par défaut. Dans les versions précédentes, le fuseau était hérité de la configuration système.

Fonctions to_date et to_timestamp

La façon de gérer les dates sur 2 et 3 chiffres n’était pas cohérente. En effet, les dates sur 2 chiffres étaient toujours converties vers la date la plus proche de 2020. Sur 3 chiffres, les dates de 100 à 999 étaient converties vers 1100 à 1999, et les dates de 000 à 099 converties vers 2000 à 2099. Dorénavant, PostgreSQL choisit la date la plus proche de 2020, pour les dates sur 2 et 3 chiffres.

En 9.1 :

=# SELECT to_date('200-07-02','YYY-MM-DD');
  to_date   
------------
 1200-07-02

En 9.2:

SELECT to_date('200-07-02','YYY-MM-DD');
  to_date   
------------
 2200-07-02

EXTRACT prend en compte le fuseau horaire local

Utiliser EXTRACT sur une valeur sans fuseau horaire prend maintenant en compte le fuseau local et non UTC.

Avec PostgreSQL 9.1 :

=#SELECT extract(epoch from '2012-07-02 00:00:00'::timestamp);
 date_part  
------------
 1341180000
(1 row)
=# SELECT extract(epoch from '2012-07-02 00:00:00'::timestamptz);
 date_part  
------------
 1341180000
(1 row)

Il n’y a aucune différence de comportement entre un timestamp et un timestamp avec fuseau horaire.

Avec PostgreSQL 9.2 :

=#SELECT extract(epoch from '2012-07-02 00:00:00'::timestamp);
 date_part  
------------
 1341187200
(1 row)

=# SELECT extract(epoch from '2012-07-02 00:00:00'::timestamptz);
 date_part  
------------
 1341180000
(1 row)

Quand le timestamp n’a pas de fuseau horaire, la valeur de epoch est calculée avec le « minuit local », c’est-à-dire le 1er janvier 1970 à minuit, heure locale.

Fonctions pg_relation_size() et affiliées

Jusqu’en version 9.1, l’appel aux fonctions pg_relation_size() et des fonctions similaires déclenchaient une exception SQL si l’objet n’existe pas. Un objet pouvant être supprimé par une session concurrente alors qu’un appel à pg_relation_size() était effectué dessus, cela pouvait être problématique.

À partir de la version 9.2, la fonction renverra NULL si l’objet n’existe pas. Exemple 9.1 :

# SELECT pg_relation_size(123);
ERROR:  could not open relation with OID 123

En 9.2 :

select pg_relation_size(123);
 pg_relation_size 
------------------

(1 ligne)

Statistiques SQL stockées en millisecondes

Les champs pg_stat_user_functions.total_time, pg_stat_user_functions.self_time, pg_stat_xact_user_functions.total_time, pg_stat_xact_user_functions.self_time et pg_stat_statements.total_time (contrib) sont maintenant en millisecondes, pour être cohérent avec toutes les autres valeurs de chronométrage.