第47章 バックグラウンドワーカプロセス

<title>Background Worker Processes</title>

PostgreSQL can be extended to run user-supplied code in separate processes. Such processes are started, stopped and monitored by <command>postgres</command>, which permits them to have a lifetime closely linked to the server's status. These processes have the option to attach to <productname>PostgreSQL</>'s shared memory area and to connect to databases internally; they can also run multiple transactions serially, just like a regular client-connected server process. Also, by linking to <application>libpq</> they can connect to the server and behave like a regular client application. PostgreSQLはユーザ提供のコードを別のプロセスとして実行できるように拡張することができます。 このプロセスはpostgresによって起動、終了、監視され、サーバの状態に密接にリンクした寿命を持つことができます。 これらのプロセスはPostgreSQLの共有メモリ領域にアタッチしたり、データベースの内部に接続するオプションを持ちます。これらはまた、通常のクライアントに接続された実際のサーバプロセスのように複数のトランザクションを連続して実行することができます。 また、アプリケーションはlibpqとリンクすることにより通常のクライアントアプリケーションのようにサーバに接続して動作することができます。

警告

There are considerable robustness and security risks in using background worker processes because, being written in the <literal>C</> language, they have unrestricted access to data. Administrators wishing to enable modules that include background worker process should exercise extreme caution. Only carefully audited modules should be permitted to run background worker processes. バックグラウンドワーカを使うにあたっては、堅牢性とセキュリティリスクを考慮しなくてはなりません。なぜならば、C言語で書かれており、データへのアクセスが制限されていないためです。 バックグラウンドワーカプロセスを含むモジュールを有効にしたいと思っている管理者は、細心の注意を払って実践してください。 バックグラウンドワーカプロセスの実行は、注意深く検査されたモジュールだけを許可する必要があります。

Background workers can be initialized at the time that <productname>PostgreSQL</> is started by including the module name in <varname>shared_preload_libraries</>. A module wishing to run a background worker can register it by calling <function>RegisterBackgroundWorker(<type>BackgroundWorker *worker</type>)</function> from its <function>_PG_init()</>. Background workers can also be started after the system is up and running by calling the function <function>RegisterDynamicBackgroundWorker(<type>BackgroundWorker *worker, BackgroundWorkerHandle **handle</type>)</function>. Unlike <function>RegisterBackgroundWorker</>, which can only be called from within the postmaster, <function>RegisterDynamicBackgroundWorker</function> must be called from a regular backend. バックグラウンドワーカは、モジュールをshared_preload_librariesに記すことによって、PostgreSQLスタート時に初期化できます。 バックグラウンドワーカとして実行したいモジュールは、_PG_init()からRegisterBackgroundWorker(BackgroundWorker *worker)を呼び出すことで登録できます。 バックグラウンドワーカはシステム起動後もRegisterDynamicBackgroundWorker(BackgroundWorker *worker, BackgroundWorkerHandle **handle)を呼び出すことによって開始することができます。 postmasterからのみ呼び出すことができるRegisterBackgroundWorkerとは異なり、RegisterDynamicBackgroundWorkerは通常のバックエンドから呼び出す必要があります。

The structure <structname>BackgroundWorker</structname> is defined thus: BackgroundWorkerの構造体は以下のように定義されます。

typedef void (*bgworker_main_type)(Datum main_arg);
typedef struct BackgroundWorker
{
    char        bgw_name[BGW_MAXLEN];
    int         bgw_flags;
    BgWorkerStartTime bgw_start_time;
    int         bgw_restart_time;       /* in seconds, or BGW_NEVER_RESTART */
    char        bgw_library_name[BGW_MAXLEN];
    char        bgw_function_name[BGW_MAXLEN];
    Datum       bgw_main_arg;
    char        bgw_extra[BGW_EXTRALEN];
    int         bgw_notify_pid;
} BackgroundWorker;

<structfield>bgw_name</> is a string to be used in log messages, process listings and similar contexts. bgw_nameは、ログメッセージ、プロセス一覧等で使用される文字列です。

<structfield>bgw_flags</> is a bitwise-or'd bit mask indicating the capabilities that the module wants. Possible values are: bgw_flagsは、モジュールが要求する機能をOR演算したビットマスクです。可能な値は以下の通りです。

BGWORKER_SHMEM_ACCESS

<indexterm><primary>BGWORKER_SHMEM_ACCESS</primary></indexterm> Requests shared memory access. Workers without shared memory access cannot access any of <productname>PostgreSQL's</productname> shared data structures, such as heavyweight or lightweight locks, shared buffers, or any custom data structures which the worker itself may wish to create and use. 共有メモリへのアクセスを要求します。 共有メモリアクセスがないワーカは、重量または軽量のロック、共有バッファ、ワーカが作成して利用したいカスタムデータ構造等、PostgreSQLの共有データ構造にアクセスできません。

BGWORKER_BACKEND_DATABASE_CONNECTION

<indexterm><primary>BGWORKER_BACKEND_DATABASE_CONNECTION</primary></indexterm> Requests the ability to establish a database connection through which it can later run transactions and queries. A background worker using <literal>BGWORKER_BACKEND_DATABASE_CONNECTION</literal> to connect to a database must also attach shared memory using <literal>BGWORKER_SHMEM_ACCESS</literal>, or worker start-up will fail. トランザクションやクエリの実行が出来るデータベース接続を要求します。 BGWORKER_BACKEND_DATABASE_CONNECTIONを使用してデータベースに接続するバックグラウンドワーカはBGWORKER_SHMEM_ACCESSを使用して共有メモリにアタッチしなければなりません。さもなければ起動時に失敗します。

<structfield>bgw_start_time</structfield> is the server state during which <command>postgres</> should start the process; it can be one of <literal>BgWorkerStart_PostmasterStart</> (start as soon as <command>postgres</> itself has finished its own initialization; processes requesting this are not eligible for database connections), <literal>BgWorkerStart_ConsistentState</> (start as soon as a consistent state has been reached in a hot standby, allowing processes to connect to databases and run read-only queries), and <literal>BgWorkerStart_RecoveryFinished</> (start as soon as the system has entered normal read-write state). Note the last two values are equivalent in a server that's not a hot standby. Note that this setting only indicates when the processes are to be started; they do not stop when a different state is reached. bgw_start_timeは、postgresがプロセスを起動するべきタイミングを指定します。 そのタイミングは、以下のうちの1つです。 BgWorkerStart_PostmasterStartpostgres自身が初期化を終えるとすぐに起動します。これを要求するプロセスはデータベース接続に望ましいものではありません)、 BgWorkerStart_ConsistentState(ホットスタンバイで一貫性のある状態に到達し、データベースに接続して参照のみのクエリが実行できるようになると起動します)、 BgWorkerStart_RecoveryFinished(システムが通常の参照/更新クエリを実行できるようになると起動します)。 最後の2つの値は、ホットスタンバイでないサーバでは同等であることに注意してください。 この設定はいつプロセスが起動されるかを示すだけであることに注意してください。 これらのプロセスは、違う状態になったときに停止するわけではありません。

<structfield>bgw_restart_time</structfield> is the interval, in seconds, that <command>postgres</command> should wait before restarting the process, in case it crashes. It can be any positive value, or <literal>BGW_NEVER_RESTART</literal>, indicating not to restart the process in case of a crash. bgw_restart_timeは、プロセスがクラッシュした場合にpostgresがそのプロセスを再起動するために待つ必要のある間隔を秒単位で指定します。 これは任意の正の値、またはクラッシュしても再起動させない場合にBGW_NEVER_RESTARTを指定します。

<structfield>bgw_library_name</structfield> is the name of a library in which the initial entry point for the background worker should be sought. The named library will be dynamically loaded by the worker process and <structfield>bgw_function_name</structfield> will be used to identify the function to be called. If loading a function from the core code, this must be set to "postgres". bgw_library_nameはバックグラウンドワーカの初期エントリーポイントのためのライブラリ名です。 その指定されたライブラリがワーカプロセスによって動的にロードされます。呼び出すべき関数を特定するためにbgw_function_nameが使用されます。 コアコードから関数をロードする場合、代わりにbgw_mainを設定する必要があります。

<structfield>bgw_function_name</structfield> is the name of a function in a dynamically loaded library which should be used as the initial entry point for a new background worker. bgw_function_nameは新しいバックグラウンドワーカから動的にロードされるときに初期エントリポイントの関数名です。

<structfield>bgw_main_arg</structfield> is the <type>Datum</> argument to the background worker main function. This main function should take a single argument of type <type>Datum</> and return <type>void</>. <structfield>bgw_main_arg</structfield> will be passed as the argument. In addition, the global variable <literal>MyBgworkerEntry</literal> points to a copy of the <structname>BackgroundWorker</structname> structure passed at registration time; the worker may find it helpful to examine this structure. bgw_main_argは、バックグラウンドワーカのメイン関数のDatum引数です。 bgw_main経由か、bgw_library_namebgw_function_nameの組み合わせ経由であるかにかかわらず、メイン関数は単一のDatum引数を取り、voidを返します。 bgw_main_argは引数として渡されます。 加えて、グローバル変数MyBgworkerEntryは、登録時に渡されたBackgroundWorker構造体のコピーを指しています。 ワーカはこの構造を調べることがあり、役に立ちます。

On Windows (and anywhere else where <literal>EXEC_BACKEND</literal> is defined) or in dynamic background workers it is not safe to pass a <type>Datum</> by reference, only by value. If an argument is required, it is safest to pass an int32 or other small value and use that as an index into an array allocated in shared memory. If a value like a <type>cstring</> or <type>text</type> is passed then the pointer won't be valid from the new background worker process. Windowsの(どこか他の場所でEXEC_BACKENDが定義されている)場合、または動的バックグラウンドワーカは、Datumを参照で渡すのは安全ではありません。値のみで渡してください。 引数が必要な場合は、int32型または他の小さな値を渡し、共有メモリに割り当てられた配列へのインデックスとしてそれを使用するのが最も安全です。 cstringtextのようなポインタを渡された場合は、新しいバックグラウンドワーカプロセスから有効になりません。

<structfield>bgw_extra</structfield> can contain extra data to be passed to the background worker. Unlike <structfield>bgw_main_arg</>, this data is not passed as an argument to the worker's main function, but it can be accessed via <literal>MyBgworkerEntry</literal>, as discussed above. bgw_extraはバックグラウンドワーカに渡す追加データを含めることが出来ます。 bgw_main_argとは異なり、このデータはワーカのメイン関数の引数として渡されていませんが、上述したようにMyBgworkerEntryを介してアクセスすることが出来ます。

<structfield>bgw_notify_pid</structfield> is the PID of a PostgreSQL backend process to which the postmaster should send <literal>SIGUSR1</> when the process is started or exits. It should be 0 for workers registered at postmaster startup time, or when the backend registering the worker does not wish to wait for the worker to start up. Otherwise, it should be initialized to <literal>MyProcPid</>. bgw_notify_pidはプロセスの開始時と終了時にpostmasterがSIGUSR1を送信するPostgreSQLバックエンドプロセスのPIDです。 それはpostmasterの起動時に登録されたワーカの場合、またはワーカを登録しているバックエンドがワーカーの起動を待ちたくない場合は0にする必要があります。 それ以外の場合は、MyProcPidで初期化する必要があります。

<para>Once running, the process can connect to a database by calling <function>BackgroundWorkerInitializeConnection(<parameter>char *dbname</parameter>, <parameter>char *username</parameter>)</function> or <function>BackgroundWorkerInitializeConnectionByOid(<parameter>Oid dboid</parameter>, <parameter>Oid useroid</parameter>)</function>. This allows the process to run transactions and queries using the <literal>SPI</literal> interface. If <varname>dbname</> is NULL or <varname>dboid</> is <literal>InvalidOid</>, the session is not connected to any particular database, but shared catalogs can be accessed. If <varname>username</> is NULL or <varname>useroid</> is <literal>InvalidOid</>, the process will run as the superuser created during <command>initdb</>. A background worker can only call one of these two functions, and only once. It is not possible to switch databases. </para>

ひとたび実行すると、このプロセスはBackgroundWorkerInitializeConnection(char *dbname, char *username)またはBackgroundWorkerInitializeConnectionByOid(Oid dboid, Oid useroid)を呼び出すことによって、データベースに接続できます。 これはプロセスにSPIインタフェースを使用してのトランザクションとクエリの実行を許します。 もし、dbnameがNULLであった場合、またはdboidInvalidOidであった場合には、そのセッションは特定のデータベースに接続しません。しかし、共有カタログにはアクセス出来ます。 もし、usernameがNULLの場合、またはuseroidInvalidOidの場合には、そのプロセスはinitdb時に作成されたスーパーユーザとして実行されます。 バックグラウンドワーカはこれら2つの関数をどちらかを一度だけ呼ぶことが出来ます。 データベースを切り替えることができません。

Signals are initially blocked when control reaches the background worker's main function, and must be unblocked by it; this is to allow the process to customize its signal handlers, if necessary. Signals can be unblocked in the new process by calling <function>BackgroundWorkerUnblockSignals</> and blocked by calling <function>BackgroundWorkerBlockSignals</>. 制御がbgw_main関数に達したとき、シグナルはまずブロックされます。このブロックはbgwmainで解除されなければなりません。 これは、必要に応じてプロセスがシグナルハンドラをカスタマイズできるようにするためです。 シグナルは新しいプロセスでBackgroundWorkerUnblockSignalsを呼び出すことにより、解除でき、BackgroundWorkerBlockSignalsを呼び出すことでブロックできます。

If <structfield>bgw_restart_time</structfield> for a background worker is configured as <literal>BGW_NEVER_RESTART</>, or if it exits with an exit code of 0 or is terminated by <function>TerminateBackgroundWorker</>, it will be automatically unregistered by the postmaster on exit. Otherwise, it will be restarted after the time period configured via <structfield>bgw_restart_time</>, or immediately if the postmaster reinitializes the cluster due to a backend failure. Backends which need to suspend execution only temporarily should use an interruptible sleep rather than exiting; this can be achieved by calling <function>WaitLatch()</function>. Make sure the <literal>WL_POSTMASTER_DEATH</> flag is set when calling that function, and verify the return code for a prompt exit in the emergency case that <command>postgres</> itself has terminated. バックグラウンドワーカは、bgw_restart_timeBGW_NEVER_RESTARTに設定されている場合、または終了コード0で終了した場合、またはTerminateBackgroundWorkerによって終了した場合、postmasterに自動的に登録が解除されて終了します。 それ以外の場合、bgw_restart_timeで設定された時間の後に再起動します。または、バックエンドの障害のためにposmasterがクラスタを再初期化した場合は、すぐに再起動します。 一時的に実行を中断するだけでよいバックエンドは、終了するのではなく、割り込み可能なスリープを使用する必要があります。 これはWaitLatch()を呼び出すことによって可能になります。 この関数を呼び出すときにはWL_POSTMASTER_DEATHフラグが設定されているか確認し、postgres自身が終了する緊急事態には、リターンコードを確認するようにしてください。

When a background worker is registered using the <function>RegisterDynamicBackgroundWorker</function> function, it is possible for the backend performing the registration to obtain information regarding the status of the worker. Backends wishing to do this should pass the address of a <type>BackgroundWorkerHandle *</type> as the second argument to <function>RegisterDynamicBackgroundWorker</function>. If the worker is successfully registered, this pointer will be initialized with an opaque handle that can subsequently be passed to <function>GetBackgroundWorkerPid(<parameter>BackgroundWorkerHandle *</parameter>, <parameter>pid_t *</parameter>)</function> or <function>TerminateBackgroundWorker(<parameter>BackgroundWorkerHandle *</parameter>)</function>. <function>GetBackgroundWorkerPid</> can be used to poll the status of the worker: a return value of <literal>BGWH_NOT_YET_STARTED</> indicates that the worker has not yet been started by the postmaster; <literal>BGWH_STOPPED</literal> indicates that it has been started but is no longer running; and <literal>BGWH_STARTED</literal> indicates that it is currently running. In this last case, the PID will also be returned via the second argument. <function>TerminateBackgroundWorker</> causes the postmaster to send <literal>SIGTERM</> to the worker if it is running, and to unregister it as soon as it is not. バックグラウンドワーカをRegisterDynamicBackgroundWorker関数により登録している場合、登録を実行するバックエンドはワーカの状態に関する情報を取得することが可能です。 取得したい場合はRegisterDynamicBackgroundWorkerに2番目の引数としてBackgroundWorkerHandle *のアドレスを渡す必要があります。 もし登録に成功した場合、このポインタは後でGetBackgroundWorkerPid(BackgroundWorkerHandle *,pid_t *)またはTerminateBackgroundWorker(BackgroundWorkerHandle *)に渡すことができるopaue(不透明)ハンドルで、初期化されます。 GetBackgroundWorkerPidはワーカの状態を監視することができます。以下の返り値が得られます。 BGWH_NOT_YET_STARTEDワーカはまだpostmasterにより開始されていない。 BGWH_STOPPED開始されたが、もはや実行されていない。 BGWH_STARTED実行中です。 この最後のケースでは、PIDは、2番目の引数を介して返されます。 TerminateBackgroundWorkerはワーカが実行していた場合postmasterがワーカにSIGTERMを送信し、実行が終了次第すぐに登録を解除します。

In some cases, a process which registers a background worker may wish to wait for the worker to start up. This can be accomplished by initializing <structfield>bgw_notify_pid</structfield> to <literal>MyProcPid</> and then passing the <type>BackgroundWorkerHandle *</type> obtained at registration time to <function>WaitForBackgroundWorkerStartup(<parameter>BackgroundWorkerHandle *handle</parameter>, <parameter>pid_t *</parameter>)</function> function. This function will block until the postmaster has attempted to start the background worker, or until the postmaster dies. If the background runner is running, the return value will <literal>BGWH_STARTED</>, and the PID will be written to the provided address. Otherwise, the return value will be <literal>BGWH_STOPPED</literal> or <literal>BGWH_POSTMASTER_DIED</literal>. 場合によっては、バックグラウンドワーカが起動するのを待ってから、ワーカを登録したい場合もあるでしょう。 これは bgw_notify_pidMyProcPidで初期化し、登録時に得られたBackgroundWorkerHandle *を使用してWaitForBackgroundWorkerStartup(BackgroundWorkerHandle *handle,pid_t *)関数を呼び出すことで実現します。 postmasterがバックグラウンドワーカを開始しようと試みたか、postmasterが死ぬまで、この関数はブロックします。 バックグラウンドランナーが実行されている場合、戻り値はBGWH_STARTED、およびPIDが提供されたアドレスに書き込まれます。 そうでない場合、戻り値はBGWH_STOPPEDまたはBGWH_POSTMASTER_DIEDになります。

If a background worker sends asynchronous notifications with the <command>NOTIFY</command> command via the Server Programming Interface (<acronym>SPI</acronym>), it should call <function>ProcessCompletedNotifies</function> explicitly after committing the enclosing transaction so that any notifications can be delivered. If a background worker registers to receive asynchronous notifications with the <command>LISTEN</command> through <acronym>SPI</acronym>, the worker will log those notifications, but there is no programmatic way for the worker to intercept and respond to those notifications. バックグラウンドワーカは、サーバプログラミングインターフェイス(SPI)経由でNOTIFYコマンドにより非同期に通知を送る場合、囲んでいるトランザクションをコミットした後、通知を配信することができるように明示的にProcessCompletedNotifiesを呼ぶ必要があります。 バックグラウンドワーカは、SPIを通じてLISTENによる非同期通知の受信を登録した場合、ワーカがこれらの通知をログに記録しますが、ワーカが傍受し、それらの通知に応答するためのプログラム的な方法はありません。

The <filename>src/test/modules/worker_spi</> module contains a working example, which demonstrates some useful techniques. バックグラウンドワーカの実例として、src/test/modules/worker_spiというモジュールがあります。 これはいくつかの有用な技術を示しています。

The maximum number of registered background workers is limited by <xref linkend="guc-max-worker-processes">. 登録できるバックグラウンドワーカの最大数はmax_worker_processesによって制限されています。