PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 17.2 » Internes » Journaux de transactions pour les extensions » Gestionnaires de ressources WAL personnalisées

63.2. Gestionnaires de ressources WAL personnalisées #

Ce chapitre explique l'interface entre le cœur du système PostgreSQL et les gestionnaires de ressources WAL personnalisées, qui permettent aux extensions de s'intégrer directement avec les WAL.

Une extension, en particulier une méthode d'accès à une table ou une méthode d'accès à un index, peut avoir besoin d'utiliser des WAL pour la restauration, la réplication et/ou le décodage logique.

Pour créer un nouveau gestionnaire de ressources WAL personnalisées, définissez d'abord une structure RmgrData avec l'implémentation des méthodes du gestionnaire de ressources. Reportez-vous à src/backend/access/transam/README et src/include/access/xlog_internal.h dans le source de PostgreSQL.

/*
 * Table de méthodes pour les gestionnaires de ressources.
 *
 * Cette structure doit rester synchronisée avec la définition de PG_RMGR dans
 * rmgr.c.
 *
 * rm_identify doit renvoyer un nom pour l'enregistrement relatif à xl_info
 * (sans référence au rmid). Par exemple, XLOG_BTREE_VACUUM serait nommé
 * "VACUUM". rm_desc peut ensuite être appelé pour obtenir des détails
 * supplémentaires pour l'enregistrement, s'ils sont disponibles (par exemple,
 * le dernier bloc).
 *
 * rm_mask prend en entrée une page modifiée par le gestionnaire de ressources
 * et masque les bits qui ne doivent pas être marqués par
 * wal_consistency_checking.
 *
 * RmgrTable[] est indexé par les valeurs de RmgrId (voir rmgrlist.h).
 * Si rm_name est NULL, l'entrée RmgrTable correspondante est considérée comme
 * invalide.
 */
typedef struct RmgrData
{
    const char *rm_name;
    void        (*rm_redo) (XLogReaderState *record);
    void        (*rm_desc) (StringInfo buf, XLogReaderState *record);
    const char *(*rm_identify) (uint8 info);
    void        (*rm_startup) (void);
    void        (*rm_cleanup) (void);
    void        (*rm_mask) (char *pagedata, BlockNumber blkno);
    void        (*rm_decode) (struct LogicalDecodingContext *ctx,
                              struct XLogRecordBuffer *buf);
} RmgrData;

Le module src/test/modules/test_custom_rmgrs contient un exemple fonctionnel démontrant l'utilisation de gestionnaires de ressources pour les journaux de transactions.

Ensuite, enregistrez votre nouveau gestionnaire de ressources.

/*
 * Enregistrer un nouveau gestionnaire de ressources WAL personnalisées.
 *
 * Les ID de gestionnaire de ressources doivent être uniques au monde pour
 * toutes les extensions. Se référer à
 * https://wiki.postgresql.org/wiki/CustomWALResourceManagers pour réserver un
 * RmgrId unique pour votre extension, afin d'éviter les conflits avec les
 * extensions d'autres développeurs. Lors du développement, utilisez
 * RM_EXPERIMENTAL_ID pour éviter la réservation inutile d'un nouvel ID.
 */
extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);

RegisterCustomRmgr doit être appelé depuis la fonction _PG_init du module d'extension. Lors du développement d'une nouvelle extension, utilisez RM_EXPERIMENTAL_ID pour rmid. Lorsque vous êtes prêt à publier l'extension pour les utilisateurs, réservez un nouvel ID de gestionnaire de ressources sur la page Custom WAL Resource Manager.

Mettez le module d'extension implémentant le gestionnaire de ressources personnalisées dans shared_preload_libraries afin qu'il soit chargé assez tôt lors du démarrage de PostgreSQL .

Note

L'extension doit rester dans shared_preload_libraries tant que des enregistrements personnalisés de WAL peuvent exister dans le système. Sinon, PostgreSQL ne pourra pas appliquer ou décoder les enregistrements personnalisés de WAL, ce qui peut empêcher le serveur de démarrer.