Utilisation des SQL fonctionnalités de Postgre prises en charge par Amazon RDS pour Postgre SQL

Amazon RDS pour Postgre SQL prend en charge la plupart des fonctionnalités Postgre SQL les plus courantes. Par exemple, Postgre SQL dispose d'une fonction d'aspiration automatique qui effectue la maintenance de routine de la base de données. La fonction d'autovacuum est active par défaut. Bien que vous puissiez désactiver cette fonction, nous vous recommandons vivement de la conserver active. Comprendre cette fonctionnalité et ce que vous pouvez faire pour vous assurer qu'elle fonctionne comme il se doit est une tâche fondamentaleDBA. Pour de plus amples informations sur l'autovacuum, veuillez consulter Utilisation de l'SQLaspirateur automatique Postgre sur Amazon RDS pour Postgre SQL. Pour en savoir plus sur les autres DBA tâches courantes, Tâches courantes d'administration de bases de données pour Amazon RDS for PostgreSQL

RDSfor Postgre prend SQL également en charge les extensions qui ajoutent des fonctionnalités importantes à l'instance de base de données. Par exemple, vous pouvez utiliser l'GISextension Post pour travailler avec des données spatiales, ou utiliser l'extension pg_cron pour planifier la maintenance depuis l'instance. Pour plus d'informations sur les SQL extensions Postgre, consultezUtilisation des SQL extensions Postgre avec Amazon RDS pour Postgre SQL.

Les enveloppeurs de données étrangères sont un type d'extension spécifique conçu pour permettre à votre RDS SQL instance de base de données Postgre de fonctionner avec d'autres bases de données ou types de données commerciaux. Pour plus d'informations sur les enveloppeurs de données étrangers pris en charge par RDS for PostgreSQL, consultez. Utilisation des wrappers de données étrangers pris en charge pour SQL

Vous trouverez ci-dessous des informations sur d'autres fonctionnalités prises en charge par RDS PostgreSQL.

Types de données et énumérations personnalisés avec RDS pour Postgre SQL

Postgre SQL prend en charge la création de types de données personnalisés et l'utilisation d'énumérations. Pour plus d'informations sur la création et l'utilisation d'énumérations et d'autres types de données, consultez la section Types énumérés dans la documentation Postgre. SQL

Voici un exemple de création d'un type en tant qu'énumération, puis d'insertion de valeurs dans une table.

CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)

Déclencheurs d'événements RDS pour Postgre SQL

Toutes les SQL versions actuelles de Postgre prennent en charge les déclencheurs d'événements, de même que toutes les versions disponibles de RDS for SQL Postgre. Vous pouvez utiliser le compte d'utilisateur principal (par défaut, postgres) pour créer, modifier, renommer et supprimer des déclencheurs d'évènements. Les déclencheurs d'évènements sont au niveau de l'instance de base de données, de sorte qu'ils peuvent s'appliquer à toutes les bases de données sur une instance.

Par exemple, le code suivant crée un déclencheur d'événement qui affiche l'utilisateur actuel à la fin de chaque commande du langage de définition des données (DDL).

CREATE OR REPLACE FUNCTION raise_notice_func()
    RETURNS event_trigger
    LANGUAGE plpgsql AS
$$
BEGIN
    RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;

CREATE EVENT TRIGGER event_trigger_1 
    ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();

Pour plus d'informations sur les déclencheurs d'SQLévénements Postgre, consultez la section Déclencheurs d'événements dans la documentation PostgreSQL.

L'utilisation des déclencheurs d'SQLévénements Postgre sur Amazon RDS est soumise à plusieurs limites. Tel est le cas des éléments suivants :

• Vous ne pouvez pas créer de déclencheurs d'évènements sur les réplicas en lecture. En revanche, vous pouvez créer de déclencheurs d'évènements sur une source de réplica en lecture. Les déclencheurs d'évènements sont ensuite copiés sur le réplica en lecture. Les déclencheurs d'évènements sur le réplica en lecture ne s'activent pas sur le réplica en lecture lorsque les modifications sont poussées depuis la source. En revanche, si le réplica en lecture est promu, les déclencheurs d'évènements existants s'activent lorsque des opérations de base de données ont lieu.

• Pour effectuer une mise à niveau de version majeure vers une SQL instance de base de données Postgre qui utilise des déclencheurs d'événements, assurez-vous de supprimer les déclencheurs d'événements avant de mettre à niveau l'instance.

De grandes pages RDS pour Postgre SQL

Les Huge pages (Grandes pages) sont une fonction de gestion de la mémoire qui réduit la surcharge lorsqu'une instance de base de données fonctionne avec de gros morceaux de mémoire contigus, tels que ceux utilisés par les tampons partagés. Cette SQL fonctionnalité de Postgre est prise en charge par toutes les versions actuellement disponibles RDS pour PostgreSQL. Vous allouez de grandes pages pour votre application en utilisant des appels à la mémoire partagée mmap ou SYSV. RDScar Postgre SQL prend en charge les tailles de page de 4 Ko et de 2 Mo.

Vous pouvez activer ou désactiver les Grandes pages en modifiant la valeur du paramètre huge_pages. La fonction est activée par défaut pour toutes les classes d'instances de base de données autres que les classes micro, petites et medium.

RDScar Postgre SQL utilise d'énormes pages en fonction de la mémoire partagée disponible. Si l'instance de base de données ne peut pas utiliser de grandes pages en raison de contraintes de mémoire partagée, Amazon RDS empêche le démarrage de l'instance de base de données. Dans ce cas, Amazon RDS définit le statut de l'instance de base de données sur un état de paramètres incompatibles. Dans ce cas, vous pouvez définir le huge_pages paramètre sur pour permettre off RDS à Amazon de démarrer l'instance de base de données.

Le paramètre shared_buffers est essentiel pour définir le pool de mémoire partagée requis pour utiliser les grandes pages. La valeur par défaut du paramètre shared_buffers utilise une macro de paramètres de base de données. Cette macro définit un pourcentage du total des 8 Ko pages disponibles pour la mémoire de l'instance de base de données. Lorsque vous utilisez des grandes pages, celles-ci se trouvent avec les grandes pages. Amazon RDS place une instance de base de données dans un état de paramètres incompatibles si les paramètres de mémoire partagée sont définis pour nécessiter plus de 90 % de la mémoire de l'instance de base de données.

Pour en savoir plus sur la gestion de SQL la mémoire Postgre, consultez la section Consommation de ressources dans la documentation PostgreSQL.

Réalisation d'une réplication logique pour Amazon RDS pour Postgre SQL

À partir de la version 10.4, RDS Postgre SQL prend en charge la SQL syntaxe de publication et d'abonnement introduite dans SQL Postgre 10. Pour en savoir plus, consultez la section Réplication logique dans la SQL documentation Postgre.

Note

Outre la fonctionnalité native de réplication SQL logique Postgre introduite dans Postgre SQL 10, RDS Postgre supporte SQL également l'extension. pglogical Pour de plus amples informations, veuillez consulter Utilisation de pglogical pour synchroniser les données entre les instances.

Vous trouverez ci-dessous des informations sur la configuration de la réplication logique RDS pour une SQL instance de base de données Postgre.

Rubriques

• Compréhension de la réplication logique et du décodage logique
• Utilisation des emplacements de réplication logique

Compréhension de la réplication logique et du décodage logique

RDSfor Postgre SQL prend en charge le streaming des modifications du journal write-ahead (WAL) à l'aide des emplacements de réplication logiques SQL de Postgre. Il prend également en charge l'utilisation du décodage logique. Vous pouvez configurer des emplacements logiques de réplication sur votre instance et diffuser les modifications de base de données à travers ces emplacements pour un client comme pg_recvlogical. Les emplacements logiques de réplication sont créés au niveau de la base de données et prennent en charge les connexions de réplication avec une base de données unique.

Les clients les plus courants pour la réplication SQL logique Postgre sont les AWS Database Migration Service hôtes gérés de manière personnalisée sur une instance AmazonEC2. L'emplacement de réplication logique ne contient aucune information sur le récepteur du flux. De plus, il n'est pas nécessaire que la cible soit une base de données de réplica. Si vous configurez un emplacement de réplication logique et que vous ne lisez pas à partir de l'emplacement, les données peuvent être écrites dans le stockage de votre instance de base de données et le remplir rapidement.

Vous activez la réplication SQL logique Postgre et le décodage logique pour Amazon à l'RDSaide d'un paramètre, d'un type de connexion de réplication et d'un rôle de sécurité. Le client pour le décodage logique peut être n'importe quel client capable d'établir une connexion de réplication à une base de données sur une instance de base de données PostgreSQL.

Pour activer le décodage logique pour et RDS pour une instance de base de données Postgre SQL

1. Assurez-vous que le compte utilisateur que vous utilisez possède les rôles suivants :

   • Le rôle rds_superuser de manière à ce que vous puissiez activer la réplication logique

   • Le rôle rds_replication pour accorder les autorisations de gérer des emplacements logiques et de diffuser les données à l'aide d'emplacements logiques

2. Définissez le paramètre statique rds.logical_replication sur 1. Dans le cadre de l'application de ce paramètre, configurez également les paramètres wal_level, max_wal_senders, max_replication_slots et max_connections. Ces modifications de paramètres peuvent augmenter WAL la génération. Par conséquent, définissez le rds.logical_replication paramètre uniquement lorsque vous utilisez des emplacements logiques.

3. Redémarrez l'instance de base de données pour que le paramètre statique rds.logical_replication prenne effet.

4. Créez un emplacement de réplication logique comme expliqué dans la section suivante. Cela nécessite que vous précisiez un plugin de décodage. Actuellement, Postgre SQL supporte RDS les plugins de sortie test_decoding et wal2json fournis avec Postgre. SQL

Pour plus d'informations sur le décodage SQL logique Postgre, consultez la documentation SQLPostgre.

Utilisation des emplacements de réplication logique

Vous pouvez utiliser des SQL commandes pour travailler avec des emplacements logiques. Par exemple, la commande suivante crée un emplacement logique nommé à test_slot l'aide du plugin test_decoding de SQL sortie Postgre par défaut.

SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name    | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)

Pour lister les emplacements logiques, utilisez la commande suivante.

SELECT * FROM pg_replication_slots;

Pour supprimer un emplacement logique, utilisez la commande suivante.

SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)

Pour plus d'exemples d'utilisation des emplacements de réplication logiques, consultez la section Exemples de décodage logique dans la documentation PostgreSQL.

Après avoir créé l'emplacement de réplication logique, vous pouvez commencer le streaming. L'exemple suivant montre comment le décodage logique est contrôlé par le protocole de streaming. Cet exemple utilise le programme pg_recvlogical, qui est inclus dans la distribution Postgre. SQL Cela nécessite que l'authentification du client soit configurée pour autoriser les connexions de réplication.

pg_recvlogical -d postgres --slot test_slot -U postgres
    --host -instance-name.111122223333.aws-region.rds.amazonaws.com 
    -f -  --start

Pour afficher le contenu de la vue pg_replication_origin_status, interrogez la fonction pg_show_replication_origin_status.

SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)

RAMdisque pour le répertoire stats_temp_directory

Vous pouvez utiliser le SQL paramètre RDS for Postgre rds.pg_stat_ramdisk_size pour spécifier la mémoire système allouée à un RAM disque pour stocker le SQL stats_temp_directory Postgre. Le paramètre de RAM disque n'est disponible que RDS pour les SQL versions 14 et antérieures de Postgre.

Avec certaines charges de travail, ce paramètre peut améliorer les performances et réduire les exigences relatives aux I/O. Pour plus d'informations à ce sujetstats_temp_directory, consultez la SQL documentation Postgre. .

Pour configurer un RAM disque pour votrestats_temp_directory, définissez le rds.pg_stat_ramdisk_size paramètre sur une valeur littérale entière dans le groupe de paramètres utilisé par votre instance de base de données. Ce paramètre est indiqué en Mo, vous devez donc utiliser une valeur entière. Les expressions, formules et fonctions ne sont pas valides pour le paramètre rds.pg_stat_ramdisk_size. Veillez à réinitialiser l'instance de base de données pour que la modification prenne effet. Pour plus d'informations sur la définition des paramètres, consultez Groupes de paramètres pour Amazon RDS.

Par exemple, la AWS CLI commande suivante définit le paramètre du RAM disque sur 256 Mo.

aws rds modify-db-parameter-group \
    --db-parameter-group-name pg-95-ramdisk-testing \
    --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"

Après le redémarrage, exécutez la commande suivante pour afficher le statut de stats_temp_directory.

postgres=> SHOW stats_temp_directory;

La commande devrait renvoyer le résultat suivant.

stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)

Tablespaces pour Postgre RDS SQL

RDScar Postgre SQL prend en charge les tablespaces pour des raisons de compatibilité. Étant donné que tout le stockage se trouve sur un seul volume logique, vous ne pouvez pas utiliser d'espaces de table pour le fractionnement ou l'isolement des I/O. Nos évaluations et notre expérience indiquent qu'un seul volume logique constitue la meilleure configuration dans la plupart des cas d'utilisation.

Le rôle est requis pour créer et utiliser des tablespaces avec votre SQL instance RDS de base de données Postgre. rds_superuser Le compte utilisateur principal de votre SQL instance de base de données RDS for Postgre (nom par défautpostgres) est membre de ce rôle. Pour de plus amples informations, veuillez consulter Comprendre les SQL rôles et les autorisations de Postgre.

Si vous spécifiez un nom de fichier lors de la création d'un espace de table, le préfixe du chemin est /rdsdbdata/db/base/tablespace. L'exemple suivant montre comment placer les fichiers d'espace de table dans /rdsdbdata/db/base/tablespace/data. Cet exemple suppose qu'un utilisateur dbadmin (rôle) existe et qu'il se soit vu accorder le rôle rds_superuser nécessaire à l'utilisateur des espaces de table.

postgres=> CREATE TABLESPACE act_data
  OWNER dbadmin
  LOCATION '/data';
CREATE TABLESPACE

Pour en savoir plus sur les tablespaces Postgre, consultez SQL Tablespaces dans la documentation Postgre. SQL

RDSpour les SQL collations Postgre EBCDIC et les autres migrations de mainframe

RDSpour les SQL versions 10 et supérieures de Postgre, incluez ICU la version 60.2, qui est basée sur Unicode 10.0 et inclut des collations provenant du référentiel de données locales communes Unicode, 32. CLDR Ces bibliothèques d'internationalisation logicielle garantissent que les codages de caractères sont présentés de manière cohérente, quel que soit le système d'exploitation ou la plateforme. Pour plus d'informations sur Unicode CLDR -32, consultez la note de mise à jour CLDR 32 sur le CLDR site Web d'Unicode. Vous pouvez en savoir plus sur les composants d'internationalisation pour Unicode (ICU) sur le site Web du Comité ICU technique (ICU-TC). Pour plus d'informations sur ICU -60, voir Download ICU 60.

À partir de la version 14.3, RDS Postgre inclut SQL également des classements qui facilitent l'intégration et la conversion des données à partir de systèmes EBCDIC basés. Le code d'échange ou EBCDICcodage décimal codé binaire étendu est couramment utilisé par les systèmes d'exploitation mainframe. Ces classements RDS fournis par Amazon sont définis de manière étroite pour ne trier que les caractères Unicode qui correspondent directement aux EBCDIC pages de code. Les caractères sont triés par ordre de EBCDIC point de code pour permettre la validation des données après la conversion. Ces classements n'incluent pas les formes dénormalisées, pas plus qu'ils n'incluent les caractères Unicode qui ne correspondent pas directement à un caractère de la page de code sourceEBCDIC.

Les mappages de caractères entre les pages de EBCDIC code et les points de code Unicode sont basés sur des tables publiées parIBM. L'ensemble complet est disponible IBM sous forme de fichier compressé à télécharger. RDSfor Postgre a SQL utilisé ces mappages avec les outils fournis par le ICU pour créer les classements répertoriés dans les tableaux de cette section. Les noms des classements incluent une langue et un pays, comme l'exige leICU. Cependant, les pages de EBCDIC code ne spécifient pas les langues, et certaines pages de EBCDIC code couvrent plusieurs pays. Cela signifie que les parties langue et pays des noms de classement dans la table sont arbitraires et qu'elles ne doivent pas nécessairement correspondre à la locale actuelle. En d'autres termes, le numéro de page de code est la partie la plus importante du nom du classement dans ce tableau. Vous pouvez utiliser n'importe laquelle des collations répertoriées dans les tableaux suivants dans n'importe quelle SQL base RDS de données Postgre.

• Unicode to EBCDIC collations table— Certains outils de migration de données du mainframe utilisent LATIN1 ou permettent d'encoder et LATIN9 de traiter des données en interne. Ces outils utilisent des schémas aller-retour pour préserver l'intégrité des données et prendre en charge la conversion inverse. Les classements de ce tableau peuvent être utilisés par des outils qui traitent les données à l'aide d'un LATIN1 codage, ce qui ne nécessite aucune manipulation particulière.

• Unicode to LATIN9 collations table— Vous pouvez utiliser ces classements dans n'importe quelle base RDS de SQL données Postgre.

Dans le tableau suivant, vous trouverez des classements disponibles dans Postgre SQL qui RDS font correspondre des pages de EBCDIC code à des points de code Unicode. Nous vous recommandons d'utiliser les classements de ce tableau pour le développement d'applications nécessitant un tri basé sur l'ordre des pages de IBM code.

Nom de la SQL collation Postgrer	Description du mappage code-page et de l'ordre de tri
da-DK-cp277-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 277 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 277
de-DE-cp273-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 273 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 273
en-GB-cp285-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 285 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 285
en-US-cp037-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 037 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 37
es-ES-cp284-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 284 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 284
fi-FI-cp278-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 278 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 278
fr-FR-cp297-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 297 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 297
it-IT-cp280-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 280 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 280
nl-BE-cp500-x-icu	Les caractères Unicode qui correspondent directement à la page de IBM EBCDIC code 500 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 500

Amazon RDS fournit un ensemble de classements supplémentaires qui trient les points de code Unicode qui correspondent aux LATIN9 caractères à l'aide des tables publiées parIBM, dans l'ordre des points de code d'origine conformément à la page de EBCDIC code des données source.

Nom de la SQL collation Postgrer	Description du mappage code-page et de l'ordre de tri
DA-DK-CP1142 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1142 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1142
DE-DE-CP1141 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1141 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1141
FR-GB-CP1146 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1146 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1146
EN-US-CP1140 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1140 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1140
ES-ES-CP1145 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1145 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1145
fi-Fi-CP1143 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1143 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1143
FR-FR-CP1147 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1147 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1147
IT-IT-CP1144 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1144 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1144
NL-BE-CP1148 m-x-icu	Les caractères Unicode qui correspondent aux LATIN9 caractères initialement convertis à partir de la page de IBM EBCDIC code 1148 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1148

Vous trouverez ci-dessous un exemple d'utilisation d'un SQL classement RDS for Postgre.

db1=> SELECT pg_import_system_collations('pg_catalog');
 pg_import_system_collations
-----------------------------
                          36
db1=> SELECT '¤' < 'a' col1;
 col1
------
 t  
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
 col1
------
 f

Nous vous recommandons d'utiliser les classements dans Unicode to EBCDIC collations table et dans le Unicode to LATIN9 collations table pour le développement d'applications qui nécessitent un tri basé sur l'ordre des pages de IBM code. Les classements suivants (suffixés par la lettre « b ») sont également visibles dans les outils d'intégration et de migration de données du mainframepg_collation, mais ils sont destinés à être utilisés par ces outils pour cartographier des pages de code AWS présentant des décalages de points de code spécifiques et nécessitant un traitement spécial lors du classement. En d'autres termes, l'utilisation des classements suivants n'est pas recommandée.

• DA-DK-277 b-x-icu

• DA-DK-1142 b-x-icu

• DE-DE-CP273 b-x-icu

• DE-DE-CP1141 b-x-icu

• FR-GB-CP1146 b-x-icu

• FR-GB-CP285 b-x-icu

• FR-US-CP037 b-x-icu

• EN-US-CP1140 b-x-icu

• ES-ES-CP1145 b-x-icu

• ES-ES-CP284 b-x-icu

• fi-Fi-CP1143 b-x-icu

• FR-FR-CP1147 b-x-icu

• FR-FR-CP297 b-x-icu

• IT-IT-CP1144 b-x-icu

• IT-IT-CP280 b-x-icu

• NL-BE-CP1148 b-x-icu

• NL-BE-CP500 b-x-icu

Pour en savoir plus sur la migration d'applications depuis des environnements mainframe vers des environnements mainframe AWS, voir Qu'est-ce que la modernisation des AWS mainframes ? .

Pour plus d'informations sur la gestion des classements dans PostgreSQL, consultez Support des classements dans la documentation PostgreSQL.