Chapter 66. Custom WAL Resource Managers
This chapter explains the interface between the corePostgreSQL system and custom WAL resource managers, which enable extensions to integrate directly with theWAL.
An extension, especially aTable Access Method orIndex Access Method, may need to use WAL for recovery, replication, and/orLogical Decoding. Custom resource managers are a more flexible alternative toGeneric WAL (which does not support logical decoding), but more complex for an extension to implement.
To create a new custom WAL resource manager, first define anRmgrData
structure with implementations for the resource manager methods. Refer tosrc/backend/access/transam/README
andsrc/include/access/xlog_internal.h
in thePostgreSQL source.
/* * Method table for resource managers. * * This struct must be kept in sync with the PG_RMGR definition in * rmgr.c. * * rm_identify must return a name for the record based on xl_info (without * reference to the rmid). For example, XLOG_BTREE_VACUUM would be named * "VACUUM". rm_desc can then be called to obtain additional detail for the * record, if available (e.g. the last block). * * rm_mask takes as input a page modified by the resource manager and masks * out bits that shouldn't be flagged by wal_consistency_checking. * * RmgrTable[] is indexed by RmgrId values (see rmgrlist.h). If rm_name is * NULL, the corresponding RmgrTable entry is considered invalid. */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;
Thesrc/test/modules/test_custom_rmgrs
module contains a working example, which demonstrates usage of custom WAL resource managers.
Then, register your new resource manager.
/* * Register a new custom WAL resource manager. * * Resource manager IDs must be globally unique across all extensions. Refer * to https://wiki.postgresql.org/wiki/CustomWALResourceManagers to reserve a * unique RmgrId for your extension, to avoid conflicts with other extension * developers. During development, use RM_EXPERIMENTAL_ID to avoid needlessly * reserving a new ID. */extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
RegisterCustomRmgr
must be called from the extension module's_PG_init function. While developing a new extension, useRM_EXPERIMENTAL_ID
forrmid
. When you are ready to release the extension to users, reserve a new resource manager ID at theCustom WAL Resource Manager page.
Place the extension module implementing the custom resource manager inshared_preload_libraries so that it will be loaded early duringPostgreSQL startup.
Note
The extension must remain in shared_preload_libraries as long as any custom WAL records may exist in the system. OtherwisePostgreSQL will not be able to apply or decode the custom WAL records, which may prevent the server from starting.