バージョンごとのドキュメント一覧

第66章 カスタムWALリソースマネージャ

<title>Custom WAL Resource Managers</title>

This chapter explains the interface between the core <productname>PostgreSQL</productname> system and custom WAL resource managers, which enable extensions to integrate directly with the <link linkend="wal"><acronym>WAL</acronym></link>. この章では、PostgreSQLコアシステムとカスタムWALリソースマネージャ間のインタフェースについて説明します。 これらは拡張モジュールがWALと直接統合できるようにします。

An extension, especially a <link linkend="tableam">Table Access Method</link> or <link linkend="indexam">Index Access Method</link>, may need to use WAL for recovery, replication, and/or <link linkend="logicaldecoding">Logical Decoding</link>. Custom resource managers are a more flexible alternative to <link linkend="generic-wal">Generic WAL</link> (which does not support logical decoding), but more complex for an extension to implement. 拡張、特にテーブルアクセスメソッドインデックスアクセスメソッドは、リカバリ、レプリケーション、および/またはロジカルデコーディングにWALを使用する必要があるかもしれません。 カスタムリソースマネージャは汎用WAL(ロジカルデコーディングをサポートしていない)に対してより柔軟な代替手段ですが、拡張を実装するにはより複雑です。

To create a new custom WAL resource manager, first define an <structname>RmgrData</structname> structure with implementations for the resource manager methods. Refer to <filename>src/backend/access/transam/README</filename> and <filename>src/include/access/xlog_internal.h</filename> in the <productname>PostgreSQL</productname> source. 新しいカスタムWALリソースマネージャを作成するためには、まずリソースマネージャメソッドの実装を持つRmgrData構造体を定義します。 PostgreSQLソースのsrc/backend/access/transam/READMEsrc/include/access/xlog_internal.hを参照してください。

/*
 * 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.
 */
/*
 * (日本語訳)
 * テーブルのリソースマネージャの方法。
 *
 * この構造体は、rmgr.cのPG_RMGR定義と同期している必要があります。
 *
 * rm_identifyは、xl_info(rmidへの参照なし)に基づくレコードの名前を返す必要があります。
 * 例えば、XLOG_BTREE_VACUUMは"VACUUM"になります。
 * その後、rm_descを呼び出して、可能であれば(最後のブロックなど)、
 * レコードの追加の詳細を取得できます。
 *
 * rm_maskリソースマネージャによって変更されたページを入力として受け取り、
 * wal_consistency_checkingによってフラグが立てられないビットをマスクします。
 *
 * RmgrTable[]はRmgrId値によってインデックス化されます(rmgrlist.hを参照)。
 * rm_nameがNULLの場合、対応するRmgrTableエントリは無効と見なされます。
 */
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;

The <filename>src/test/modules/test_custom_rmgrs</filename> module contains a working example, which demonstrates usage of custom WAL resource managers. 実例としてsrc/test/modules/test_custom_rmgrsモジュールがあります。そこではカスタムWALリソースマネージャの使い方を示しています。

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.
 */
/*
 * (日本語訳)
 * カスタムWALリソースマネージャの登録。
 *
 * リソースマネージャIDは、すべての拡張にわたってグローバルにユニークである必要があります。
 * https://wiki.postgresql.org/wiki/CustomWALResourceManagers を参照して、
 * 拡張のユニークRmgrIdを予約し、他の拡張開発者との競合を回避します。
 * 開発時には、RM_EXPERIMENTAL_IDを使用して、新しいIDが不必要に予約されないようにします。
 */
extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);

<function>RegisterCustomRmgr</function> must be called from the extension module's <link linkend="xfunc-c-dynload">_PG_init</link> function. While developing a new extension, use <literal>RM_EXPERIMENTAL_ID</literal> for <parameter>rmid</parameter>. When you are ready to release the extension to users, reserve a new resource manager ID at the <ulink url="https://wiki.postgresql.org/wiki/CustomWALResourceManagers">Custom WAL Resource Manager</ulink> page. RegisterCustomRmgrは拡張モジュールの_PG_init関数から呼び出される必要があります。 新しい拡張を開発する際には、rmidRM_EXPERIMENTAL_IDを使用してください。 拡張をユーザにリリースする準備ができたら、Custom WAL Resource Managerのページで新しいリソースマネージャIDを予約してください。

Place the extension module implementing the custom resource manager in <xref linkend="guc-shared-preload-libraries"/> so that it will be loaded early during <productname>PostgreSQL</productname> startup. カスタムリソースマネージャを実装する拡張モジュールをshared_preload_librariesに配置して、PostgreSQLの起動の初期にロードされるようにします。

注記

The extension must remain in shared_preload_libraries as long as any custom WAL records may exist in the system. Otherwise <productname>PostgreSQL</productname> will not be able to apply or decode the custom WAL records, which may prevent the server from starting. 拡張モジュールは、システム内にカスタムWALレコードが存在する限り、shared_preload_libraries内に保持されなければなりません。 そうしないとPostgreSQLはカスタムWALレコードを適用またはデコードすることができず、サーバの起動を妨げる可能性があります。