PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 15BETA4 » Internes » Gestionnaires de ressources WAL personnalisées

Chapitre 66. 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. Les gestionnaires de ressources personnalisés sont une alternative plus flexible aux enregistrements génériques des WAL (qui ne prennent pas en charge le décodage logique), mais plus complexes à implémenter dans une extension.

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;

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/CustomWALResourceManager 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, 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.