After entering pipeline mode, the application dispatches requests using <xref linkend="libpq-PQsendQueryParams"/> or its prepared-query sibling <xref linkend="libpq-PQsendQueryPrepared"/>. These requests are queued on the client-side until flushed to the server; this occurs when <xref linkend="libpq-PQpipelineSync"/> is used to establish a synchronization point in the pipeline, or when <xref linkend="libpq-PQflush"/> is called. The functions <xref linkend="libpq-PQsendPrepare"/>, <xref linkend="libpq-PQsendDescribePrepared"/>, <xref linkend="libpq-PQsendDescribePortal"/>, <xref linkend="libpq-PQsendClosePrepared"/>, and <xref linkend="libpq-PQsendClosePortal"/> also work in pipeline mode. Result processing is described below. 《マッチ度[80.000000]》パイプラインモードに入った後、アプリケーションはPQsendQueryParams、またはその準備された問い合わせ版の兄弟であるPQsendQueryPreparedを使用して要求を登録します。 これらの要求は、サーバにフラッシュされるまでクライアント側で待ち行列に入れられます。 これは、PQpipelineSyncがパイプラインに同期ポイントを確立するために使用された場合、またはPQflushが呼び出された場合に発生します。 PQsendPrepare、PQsendDescribePrepared、PQsendDescribePortalの関数もパイプラインモードで動作します。 結果の処理については後述します。 《機械翻訳》パイプラインモードに入った後、アプリケーションはPQsendQueryParamsまたはその準備されたクエリの兄弟PQsendQueryPreparedを使用して要求をディスパッチします。 これらの要求は、サーバにフラッシュされるまでクライアント側でキューに入れられます。 これは、PQpipelineSyncを使用してパイプライン内に同期点を確立する場合、またはPQflushを呼び出す場合に発生します。 関数PQsendPrepare、PQsendDescribePrepared、PQsendDescribePortal、PQsendClosePrepared、PQsendClosePortalもパイプラインモードで動作します。 結果の処理については後述する。

The server executes statements, and returns results, in the order the client sends them. The server will begin executing the commands in the pipeline immediately, not waiting for the end of the pipeline. Note that results are buffered on the server side; the server flushes that buffer when a synchronization point is established with either <function>PQpipelineSync</function> or <function>PQsendPipelineSync</function>, or when <function>PQsendFlushRequest</function> is called. If any statement encounters an error, the server aborts the current transaction and does not execute any subsequent command in the queue until the next synchronization point; a <literal>PGRES_PIPELINE_ABORTED</literal> result is produced for each such command. (This remains true even if the commands in the pipeline would rollback the transaction.) Query processing resumes after the synchronization point. 《マッチ度[86.711712]》サーバは文を実行し、クライアントが送信した順に結果を返します。 サーバはパイプラインのコマンドの実行を即座に開始し、パイプラインの終了を待機しません。 結果はサーバ側でバッファされることに注意してください;同期ポイントがPQpipelineSyncで確立されたとき、またはPQsendFlushRequestが呼び出されたとき、サーバはバッファをフラッシュします。 いずれかの文でエラーが発生した場合、サーバは現在のトランザクションを中止し、次の同期ポイントまでキュー内の後続のコマンドを実行しません。 このようなコマンドごとにPGRES_PIPELINE_ABORTED結果が生成されます(パイプラインのコマンドがトランザクションをロールバックする場合でも同様です)。 問い合わせ処理は同期ポイント後に再開されます。 《機械翻訳》サーバは、クライアントが送信した順序で文を実行し、結果を返します。 サーバはパイプラインの終わりを待たずに、直ちにパイプライン内のコマンドの実行を開始します。 結果はサーバ側でバッファリングされることに注意してください。 同期点がPQpipelineSyncかPQsendPipelineSyncのどちらか、あるいはPQsendFlushRequestが呼び出された時点でサーバがそのバッファをフラッシュします。 いずれかの文がエラーを検出すると、サーバは現在のトランザクションを中断し、次の同期点までキュー内の後続のコマンドを実行しません。 このようなコマンドごとにPGRES_PIPELINE_ABORTEDの結果が生成されます。 （パイプラインのコマンドがトランザクションをロールバックする場合でも、この状態は変わりません）。 同期点の後でクエリ処理が再開されます。

It's fine for one operation to depend on the results of a prior one; for example, one query may define a table that the next query in the same pipeline uses. Similarly, an application may create a named prepared statement and execute it with later statements in the same pipeline. 1つの操作が前の操作の結果に依存することは問題ありません。 たとえば、1つの問い合わせが同じパイプラインの次の問い合わせが使用するテーブルを定義することができます。 同様に、アプリケーションは名前付きのプリペアドステートメントを作成し、同じパイプラインの後のステートメントで実行することができます。

To process the result of one query in a pipeline, the application calls <function>PQgetResult</function> repeatedly and handles each result until <function>PQgetResult</function> returns null. The result from the next query in the pipeline may then be retrieved using <function>PQgetResult</function> again and the cycle repeated. The application handles individual statement results as normal. When the results of all the queries in the pipeline have been returned, <function>PQgetResult</function> returns a result containing the status value <literal>PGRES_PIPELINE_SYNC</literal> パイプラインの1つの問い合わせの結果を処理するために、アプリケーションはPQgetResultを繰り返し呼び出し、PQgetResultがNULLを返すまで各結果を処理します。 パイプラインの次の問い合わせの結果は、再度PQgetResultを使用して取得され、サイクルが繰り返されます。 アプリケーションは個々の文の結果を通常どおり処理します。 パイプラインのすべての問い合わせの結果が返されると、PQgetResultは状態値PGRES_PIPELINE_SYNCを含む結果を返します。

The client may choose to defer result processing until the complete pipeline has been sent, or interleave that with sending further queries in the pipeline; see <xref linkend="libpq-pipeline-interleave"/>. クライアントは、完全なパイプラインが送信されるまで結果処理を延期するか、パイプラインでさらに問い合わせを送信して結果処理をインターリーブするかを選択できます。 32.5.1.4を参照してください。

<function>PQgetResult</function> behaves the same as for normal asynchronous processing except that it may contain the new <type>PGresult</type> types <literal>PGRES_PIPELINE_SYNC</literal> and <literal>PGRES_PIPELINE_ABORTED</literal>. <literal>PGRES_PIPELINE_SYNC</literal> is reported exactly once for each <function>PQpipelineSync</function> or <function>PQsendPipelineSync</function> at the corresponding point in the pipeline. <literal>PGRES_PIPELINE_ABORTED</literal> is emitted in place of a normal query result for the first error and all subsequent results until the next <literal>PGRES_PIPELINE_SYNC</literal>; see <xref linkend="libpq-pipeline-errors"/>. 《マッチ度[86.036036]》PQgetResultは通常の非同期処理と同じように動作しますが、新しいPGresult型PGRES_PIPELINE_SYNCとPGRES_PIPELINE_ABORTEDが含まれる場合があります。 PGRES_PIPELINE_SYNCは、パイプラインの対応するポイントの各PQpipelineSyncごとに1回だけ報告されます。 最初のエラーに対する通常の問い合わせ結果の代わりにPGRES_PIPELINE_ABORTEDが出力され、次のPGRES_PIPELINE_SYNCまでのすべての結果が出力されます。 32.5.1.3を参照してください。 《機械翻訳》PQgetResultは、通常の非同期処理と同じように動作しますが、新しいPGresult型PGRES_PIPELINE_SYNCとPGRES_PIPELINE_ABORTEDを含むことがあります。 PGRES_PIPELINE_SYNCは、対応するパイプラインのポイントでPQpipelineSyncまたはPQsendPipelineSyncごとに1回だけ報告されます。 最初のエラーとそれに続くPGRES_PIPELINE_SYNCまでのすべての結果に対して、通常の問い合わせ結果の代わりにPGRES_PIPELINE_ABORTEDが発行されます。 32.5.1.3を参照してください。

<function>PQisBusy</function>, <function>PQconsumeInput</function>, etc operate as normal when processing pipeline results. In particular, a call to <function>PQisBusy</function> in the middle of a pipeline returns 0 if the results for all the queries issued so far have been consumed. パイプラインの結果を処理する場合、PQisBusyやPQconsumeInputなどは通常どおりに動作します。 特に、パイプラインの途中でPQisBusyを呼び出した場合、これまでに発行されたすべての問い合わせの結果が消費されていれば0を返します。

<application>libpq</application> does not provide any information to the application about the query currently being processed (except that <function>PQgetResult</function> returns null to indicate that we start returning the results of next query). The application must keep track of the order in which it sent queries, to associate them with their corresponding results. Applications will typically use a state machine or a FIFO queue for this. libpqは、現在処理されている問い合わせに関する情報をアプリケーションに提供しません(PQgetResultはNULLを返し、次の問い合わせの結果を返し始めることを示します)。 アプリケーションは、問い合わせを送信した順序を追跡し、対応する結果と関連付ける必要があります。 アプリケーションは通常、ステートマシンまたはFIFOキューを使用します。

From the client's perspective, after <function>PQresultStatus</function> returns <literal>PGRES_FATAL_ERROR</literal>, the pipeline is flagged as aborted. <function>PQresultStatus</function> will report a <literal>PGRES_PIPELINE_ABORTED</literal> result for each remaining queued operation in an aborted pipeline. The result for <function>PQpipelineSync</function> or <function>PQsendPipelineSync</function> is reported as <literal>PGRES_PIPELINE_SYNC</literal> to signal the end of the aborted pipeline and resumption of normal result processing. 《マッチ度[84.826325]》クライアント側から見ると、PQresultStatusがPGRES_FATAL_ERRORを返した後、パイプラインは中断されたフラグが立てられます。 PQresultStatusは、中断されたパイプラインの残りのキュー操作ごとにPGRES_PIPELINE_ABORTED結果を報告します。 PQpipelineSyncの結果はPGRES_PIPELINE_SYNCとして報告され、中断されたパイプラインの終了と通常の結果処理の再開を通知します。 《機械翻訳》クライアントの観点からは、PQresultStatusがPGRES_FATAL_ERRORを返した後、パイプラインは中止されたものとしてフラグが立てられます。 中止されたパイプライン内の残りの各待ち行列操作に対して、PQresultStatusはPGRES_PIPELINE_ABORTEDの結果を報告します。 PQpipelineSyncまたはPQsendPipelineSyncの結果は、中断されたパイプラインの終了と通常の結果処理の再開を知らせるためにPGRES_PIPELINE_SYNCとして報告されます。

The client <emphasis>must</emphasis> process results with <function>PQgetResult</function> during error recovery. クライアントは、エラー修復中にPQgetResultで結果を処理しなければなりません。

If the pipeline used an implicit transaction, then operations that have already executed are rolled back and operations that were queued to follow the failed operation are skipped entirely. The same behavior holds if the pipeline starts and commits a single explicit transaction (i.e. the first statement is <literal>BEGIN</literal> and the last is <literal>COMMIT</literal>) except that the session remains in an aborted transaction state at the end of the pipeline. If a pipeline contains <emphasis>multiple explicit transactions</emphasis>, all transactions that committed prior to the error remain committed, the currently in-progress transaction is aborted, and all subsequent operations are skipped completely, including subsequent transactions. If a pipeline synchronization point occurs with an explicit transaction block in aborted state, the next pipeline will become aborted immediately unless the next command puts the transaction in normal mode with <command>ROLLBACK</command>. パイプラインで暗黙的なトランザクションが使用された場合、すでに実行された操作はロールバックされ、失敗した操作に続くキューに入れられていた操作は完全にスキップされます。 パイプラインが開始され、単一の明示的なトランザクションをコミットした場合(つまり、最初の文がBEGIN、最後の文がCOMMIT)と同じ動作が成立します。 ただし、セッションはパイプラインの終了時に中断されたトランザクション状態のままです。 パイプラインに複数の明示的なトランザクションが含まれている場合、エラー以前にコミットされたすべてのトランザクションはコミットされたままになり、現在進行中のトランザクションは中断され、後続のトランザクションも含めて後続のすべての操作は完全にスキップされます。 パイプライン同期ポイントが中断状態の明示的なトランザクションブロックで発生した場合、次のコマンドがROLLBACKを使用してトランザクションを通常モードにしない限り、次のパイプラインは即時に中断されます。

To avoid deadlocks on large pipelines the client should be structured around a non-blocking event loop using operating system facilities such as <function>select</function>, <function>poll</function>, <function>WaitForMultipleObjectEx</function>, etc. 大規模なパイプラインでデッドロックを回避するためには、クライアントはselect、poll、WaitForMultipleObjectExなどのオペレーティングシステム機能を使用して、ノンブロッキングイベントループを中心に構築する必要があります。

The client application should generally maintain a queue of work remaining to be dispatched and a queue of work that has been dispatched but not yet had its results processed. When the socket is writable it should dispatch more work. When the socket is readable it should read results and process them, matching them up to the next entry in its corresponding results queue. Based on available memory, results from the socket should be read frequently: there's no need to wait until the pipeline end to read the results. Pipelines should be scoped to logical units of work, usually (but not necessarily) one transaction per pipeline. There's no need to exit pipeline mode and re-enter it between pipelines, or to wait for one pipeline to finish before sending the next. 通常、クライアントアプリケーションは、登録される残りの作業キューと、登録されたがまだ結果が処理されていない作業キューを維持する必要があります。 ソケットが書き込み可能な場合は、より多くの作業を登録する必要があります。 ソケットが読み取り可能な場合は、結果を読み取って処理し、対応する結果キュー内の次のエントリと一致させる必要があります。 使用可能なメモリに基づいて、ソケットからの結果は頻繁に読み取られる必要があります:結果を読み取るためにパイプラインが終了するまで待つ必要はありません。 パイプラインは、通常(必ずしも必要ではありません)パイプラインごとに1つのトランザクションである論理作業単位にスコープされる必要があります。 パイプラインモードを終了してパイプライン間で再入力したり、次のパイプラインを送信する前に1つのパイプラインが終了するのを待つ必要はありません。

An example using <function>select()</function> and a simple state machine to track sent and received work is in <filename>src/test/modules/libpq_pipeline/libpq_pipeline.c</filename> in the PostgreSQL source distribution. 送受信された作業を追跡するためにselect()と単純なステートマシンを使用する例は、PostgreSQLソース配布物のsrc/test/modules/libpq_pipeline/libpq_pipeline.cにあります。