This section describes the message flow. There are four different types of flows depending on the state of the connection: startup, query, function call, and termination. There are also special provisions for notification responses and command cancellation, which can occur at any time after the startup phase.
この章ではメッセージの流れに付いて記載します。接続の状況、つまり、開始、 問い合わせ、関数呼び出し、終了フェーズによって４つの異なった流れがあります。 開始フェーズ以降の任意の時点で発生し得る通知回答と命令取り消しには、特別な 規定が存在します。
Startup is divided into an authentication phase and a backend startup phase.
開始フェーズは、認証フェーズとバックエンド開始フェーズに分割されます。
Initially, the frontend sends a StartupPacket. The postmaster uses this info and the contents of the pg_hba.conf(5) file to determine what authentication method the frontend must use. The postmaster then responds with one of the following messages:
始めにフロントエンドは StartupPacket を送ります。 postmaster はこのパケットの 情報と gp_hba.conf(5) ファイルの内容から、フロントエンドが使用すべき認証方法を 決定し、続いて以下のメッセージのどれか一つを返します。
The postmaster then immediately closes the connection.
この後すぐ postmaster は接続を解除します。
The postmaster then hands over to the backend. The postmaster takes no further part in the communication.
この後 postmaster はバックエンドに引き継ぎます。 postmaster は 以降通信に関与しません。
The frontend must then take part in a Kerberos V4 authentication dialog (not described here) with the postmaster. If this is successful, the postmaster responds with an AuthenticationOk, otherwise it responds with an ErrorResponse.
この後フロントエンドは postmaster と Kerberos V4 の認証手続き (ここでは説明しません)を開始しなければなりません。成功すると、 postmaster は AuthenticationOk を返します。不成功の場合は ErrorResponse を返します。
The frontend must then take part in a Kerberos V5 authentication dialog (not described here) with the postmaster. If this is successful, the postmaster responds with an AuthenticationOk, otherwise it responds with an ErrorResponse.
この後フロントエンドは postmaster と Kerberos V5 の認証手続き (ここでは説明しません)を開始しなければなりません。成功すると、 postmaster は AuthenticationOk を返します。不成功の場合は ErrorResponse を返します。
<-- The frontend must then send an UnencryptedPasswordPacket. If this is the correct password, the postmaster responds with an AuthenticationOk, otherwise it responds with an ErrorResponse. --> この後フロントエンドは UnencryptedPasswordPacket を送出しなければ なりません。もしこのパスワードが正しければ、 postmaster は AuthenticationOk を返します。不成功の場合は ErrorResponse を返し ます。
The frontend must then send an EncryptedPasswordPacket. If this is the correct password, the postmaster responds with an AuthenticationOk, otherwise it responds with an ErrorResponse.
この後フロントエンドは EncryptedPasswordPacket を送出しなければ なりません。もしこのパスワードが正しければ、 postmaster は AuthenticationOk を返します。不成功の場合は ErrorResponse を返し ます。
If the frontend does not support the authentication method requested by the postmaster, then it should immediately close the connection.
postmaster が要求する認証方式をフロントエンドがサポートしない場合、接続を即座 に解除しなければなりません。
After sending AuthenticationOk, the postmaster attempts to launch a backend process. Since this might fail, or the backend might encounter a failure during startup, the frontend must wait for the backend to acknowledge successful startup. The frontend should send no messages at this point. The possible messages from the backend during this phase are:
AuthenticationOk を送出後 postmaster はバックエンドプロセスの立ち上げにかか ります。これに失敗するかまたはバックエンドに起動段階で不首尾があった場合、 フロントエンドはバックエンドが正常に起動するのを待たなければなりません。 この時点ではフロントエンドは何のメッセージも送りません。この段階でバックエンド から送られるメッセージとしては以下のものがあります。
This message is issued after successful backend startup. It provides secret-key data that the frontend must save if it wants to be able to issue cancel requests later. The frontend should not respond to this message, but should continue listening for a ReadyForQuery message.
このメッセージはバックエンドが起動に成功した時に送出されます。 これは、後にフロントエンドが取り消しリクエストを出す事が出来る ようにするため保存しておくべき秘密鍵データを提供します。フロント エンドはこのメッセージに応答してはいけませんが、ReadyForQuery メッセージを受信し続ける必要があります。
Backend startup is successful. The frontend may now issue query or function call messages.
バックエンドの開始が成功しました。フロントエンドは問い合わせ または関数呼び出しメッセージを送ることが出来ます。
Backend startup failed. The connection is closed after sending this message.
バックエンドの起動に失敗しました。このメッセージ送出後、 接続は解除されます。
A warning message has been issued. The frontend should display the message but continue listening for ReadyForQuery or ErrorResponse.
警告メッセージが出されました。フロントエンドはこのメッセージを 表示しなくてはなりませんが、引続き ReadyForQuery または ErrorResponse を受信し続けます。
The ReadyForQuery message is the same one that the backend will issue after each query cycle. Depending on the coding needs of the frontend, it is reasonable to consider ReadyForQuery as starting a query cycle (and then BackendKeyData indicates successful conclusion of the startup phase), or to consider ReadyForQuery as ending the startup phase and each subsequent query cycle.
ReadyForQuery メッセージは各問い合わせサイクルの後にバックエンドが出すものと 同じものです。フロントエンドのコーディングにおいて必要であれば、ReadyForQuery を問い合わせサイクルの開始と見なしてもよい(そして BackendKeyData により開始 フェーズの正常終了が通知されます)し、開始フェーズとそれに続く各問い合わせサイ クルの終了と見なしてもよいでしょう。
A Query cycle is initiated by the frontend sending a Query message to the backend. The backend then sends one or more response messages depending on the contents of the query command string, and finally a ReadyForQuery response message. ReadyForQuery informs the frontend that it may safely send a new query or function call.
一つの問い合わせサイクルはフロントエンドがバックエンドに問い合わせメッセージ を送ることで起動されます。そこでバックエンドは問い合わせ命令の文字列の内容 に基づいて一つまたは複数の回答メッセージを送り、最終的に ReadyForQuery 回答 メッセージを送出します。ReadyForQuery はフロントエンドに確実に新規の問い合わ せまたは関数呼び出しを行っても良いことを伝えます。
The possible response messages from the backend are:
バックエンドからの送られるメッセージとしては以下のものがあげられます。
An SQL command completed normally.
SQL コマンドが正常に終了しました。
The backend is ready to copy data from the frontend to a relation. The frontend should then send a CopyDataRows message. The backend will then respond with a CompletedResponse message with a tag of "COPY".
バックエンドがフロントエンドからのデータをリレーションに コピーする準備が出来ました。フロントエンドはここで CopyDataRows メッセージを送出しなければなりません。そこで、バックエンドは 「COPY」と言う文字列のタグを付けた CompletedResponse をメッセージを 返します。
The backend is ready to copy data from a relation to the frontend. It then sends a CopyDataRows message, and then a CompletedResponse message with a tag of "COPY".
バックエンドがフロントエンドからのデータをリレーションにコピー する準備が出来ました。バックエンドはここで CopyDataRows メッ セージに引き続き、「COPY」と言う文字列のタグを付けた CompletedResponse メッセージを返します。
The query was either an insert(l), delete(l), update(l), fetch(l) or a select(l) command. If the transaction has been aborted then the backend sends a CompletedResponse message with a tag of "*ABORT STATE*". Otherwise the following responses are sent.
問い合わせは insert(l)、 delete(l)、 update(1)、fetch(l) または select(l) 命令のいずれかです。トランザクションが中断された場合、 バックエンドは 「*ABORT STATE*」 と言う文字列のタグを付けた CompletedResponse メッセージを送ります。それ以外では、以下の 応答があります。
For an insert(l) command, the backend then sends a CompletedResponse message with a tag of "INSERT oid rows" where rows is the number of rows inserted, and oid is the object ID of the inserted row if rows is 1, otherwise oid is 0.
insert(l) 命令に対し、バックエンドは 「INSERT oid rows」 と言う文字列の タグを付けた CompleteResponse メッセージを送出します。 ここで、rows は挿入された行の数で、 rows が 1 の場合 oid は挿入された行のオブジェクト識別子 で、それ以外の場合は oid は 0 です。
For a delete(l) command, the backend then sends a CompletedResponse message with a tag of "DELETE rows" where rows is the number of rows deleted.
delete(l) 命令に対し、バックエンドは 「DELETE rows 」と言う文字列のタグを付けた CompletedResponse メッ セージを返します。 ここで、rows は削除された行数です。
For an update(l) command, the backend then sends a CompletedResponse message with a tag of "UPDATE rows" where rows is the number of rows deleted.
update(l) 命令対し、バックエンドは 「UPDATE rows 」と言う文字列のタグを付けた CompletedResponse メッセージを返します。 ここで、rows は削除された行数です。
For a fetch(l) or select(l) command, the backend sends a RowDescription message. This is then followed by an AsciiRow or BinaryRow message (depending on whether a binary cursor was specified) for each row being returned to the frontend. Finally, the backend sends a CompletedResponse message with a tag of "SELECT".
fetch(l) または select(l) コマンドに対し、バックエンドは RowDescription メッセージを返します。この後続いて(バイナリカーソル が指定されているかどうかにより)フロントエンドに返されるそれぞれの 行に対して AsciiRow または BinaryRow メッセージが続きます。最後に バックエンドは 「SELECT」と言う文字列のタグを付けた CompletedResponse メッセージを送出します。
An empty query string was recognized. (The need to specially distinguish this case is historical.)
空の問い合わせ文字列が検出されました。(特別にこのケースを識別する 必要性は現在ありません。)
An error has occurred.
エラーが起こりました。
Processing of the query string is complete. A separate message is sent to indicate this because the query string may contain multiple SQL commands. (CompletedResponse marks the end of processing one SQL command, not the whole string.) ReadyForQuery will always be sent, whether processing terminates successfully or with an error.
問い合わせ文字列の処理が完了しました。問い合わせ文字列は複数 の SQL 命令を含む場合もあるため、別個のメッセージがこの結果を 示すために送出されます。(CompletedResponse は全ての文字列では 無く、一つの SQL 命令 の処理の終了の印です。) ReadyForQuery は 処理が正常に終ったかエラーとなったかに関らず、常に送られます。
A warning message has been issued in relation to the query. Notices are in addition to other responses, ie. the backend will continue processing the command.
警告メッセージは特定の問い合わせに関連して出されます。警告は バックエンドが命令の処理を引続き行うという、他の応答に対する 追加のメッセージです。
A frontend must be prepared to accept ErrorResponse and NoticeResponse messages whenever it is expecting any other type of message.
フロントエンドは他の種類のメッセージを待っているかどうかに関わらず、 ErrorResponse と NoticeResponse メッセージを受け取れる状態になって いなければなりません。
Actually, it is possible for NoticeResponse to arrive even when the frontend is not expecting any kind of message, that is, the backend is nominally idle. (In particular, the backend can be commanded to terminate by its postmaster. In that case it will send a NoticeResponse before closing the connection.) It is recommended that the frontend check for such asynchronous notices just before issuing any new command.
実際には、フロントエンドがメッセージの到着を全く予期していないような状態でも、 NoticeResponse が送られて来ることがあります。すなわち、実際にはフロント エンドがメッセージの到着を全く予期していないような状況でも、NoticeResponse が送られてくることがあり得ます。これはバックエンドのアイドル状態が、文字どお りの「待機状態」であるとは限らない、ということです。(特に、バックエンドは自身 が対応する postmaster によって終了させられることがあり、この場合、バックエンド は接続を解除する前に NoticeResponse を送ります。)フロントエンドには新しい命令 を出す直前に、このような非同期の通知の検証をすることを推奨します。
Also, if the frontend issues any listen(l) commands then it must be prepared to accept NotificationResponse messages at any time; see below.
同時に、フロントエンドが listen(l) 命令を出した場合、いつでも NotificationResponse メッセージを受け取る準備が出来ていることが必要です。 以下を参照。
A Function Call cycle is initiated by the frontend sending a FunctionCall message to the backend. The backend then sends one or more response messages depending on the results of the function call, and finally a ReadyForQuery response message. ReadyForQuery informs the frontend that it may safely send a new query or function call.
関数呼び出しサイクルはフロントエンドが FunctionCall メッセージをバックエンドに 送ることで起動されます。バックエンドは一つ又はそれ以上の応答メッセージを関数呼 び出しの結果に基づいて送り、最終的に ReadyForQuery メッセージを送出します。 ReadyForQuery はフロントエンドに対し新規の問い合わせ又は関数呼び出しを行っても 安全確実であることを通知します。
The possible response messages from the backend are:
バックエンドからの応答メッセージとして以下があげられます。
An error has occurred.
エラーが起こりました。
The function call was executed and returned a result.
関数呼び出しが処理され結果が返されました。
The function call was executed and returned no result.
関数呼び出しは処理されましたが結果は返されませんでした。
Processing of the function call is complete. ReadyForQuery will always be sent, whether processing terminates successfully or with an error.
関数呼び出しの処理が終了しました。 処理が成功またはエラーで 終了したに関わらず ReadyForQuery が常に送出されます。
A warning message has been issued in relation to the function call. Notices are in addition to other responses, ie. the backend will continue processing the command.
関数呼び出しに関して警告メッセージが出されました。警告メッセージ はバックエンドが命令を引続き処理するという他の応答に対する追加の メッセージです。
A frontend must be prepared to accept ErrorResponse and NoticeResponse messages whenever it is expecting any other type of message. Also, if it issues any listen(l) commands then it must be prepared to accept NotificationResponse messages at any time; see below.
フロントエンドは他の種類のメッセージの到着を待機しているかどうかに関わらず、 ErrorResponse と NoticeResponse メッセージを受け取る準備が出来ていなければ なりません。同時に listen(l) コマンドを送出した場合、常時 NotificationResponse メッセージを受け取れる準備が出来ていなくてはなりません。下記参照。
If a frontend issues a listen(l) command, then the backend will send a NotificationResponse message (not to be confused with NoticeResponse!) whenever a notify(l) command is executed for the same notification name.
フロントエンドが listen(l) 命令を送出し、その後これと同じ通知名に対し notify(l) 命令が実行されると、バックエンドは NofificationResponse メッセージ (NoticeResponse と間違えないように！)を送出します。
Notification responses are permitted at any point in the protocol (after startup), except within another backend message. Thus, the frontend must be prepared to recognize a NotificationResponse message whenever it is expecting any message. Indeed, it should be able to handle NotificationResponse messages even when it is not engaged in a query.
(起動後において)通知応答は、他のバックエンドメッセージの処理シーケンスの 途中でない限り、任意の時点で発行出来ます。 従って、フロントエンドは他の メッセージを待機しているかどうかに関らず NotificationResponse メッセージ を受け取れる準備が出来ていなければなりません。実際、問い合わせに関与して いない時でも NotificationResponse を処理することが出来なければなりません。
A notify(l) command has been executed for a name for which a previous listen(l) command was executed. Notifications may be sent at any time.
前の listen(l) 命令が実行された名前に対し notify(l) 命令が 実行されました。通知メッセージはいつでも出せる状態です。
It may be worth pointing out that the names used in listen and notify commands need not have anything to do with names of relations (tables) in the SQL database. Notification names are simply arbitrarily chosen condition names.
listen および notify 命令で使用される名前は、SQL データベース内のリレー ション(テーブル)の名前とは関係ない事を指摘しておいたほうが良いでしょう。 通知名は単に勝手に選択された状態の名称です。
During the processing of a query, the frontend may request cancellation of the query by sending an appropriate request to the postmaster. The cancel request is not sent directly to the backend for reasons of implementation efficiency: we don't want to have the backend constantly checking for new input from the frontend during query processing. Cancel requests should be relatively infrequent, so we make them slightly cumbersome in order to avoid a penalty in the normal case.
問い合わせの処理中に、フロントエンドは postmaster に対し適切なリクエストを送る ことによりその問い合わせを取り消すことが出来ます。取り消しリクエストは効率性を 高めるために直接バックエンドに送られません。問い合わせ処理中にバックエンドが 定期的ににフロントエンドからの入力を確かめる事は、好ましくないからです。取り消し リクエストは大抵の場合、頻繁はに起こらないので、通常の状態においての不便を避け るため、多少扱いにくくなっています。
To issue a cancel request, the frontend opens a new connection to the postmaster and sends a CancelRequest message, rather than the StartupPacket message that would ordinarily be sent across a new connection. The postmaster will process this request and then close the connection. For security reasons, no direct reply is made to the cancel request message.
取り消しリクエストを出す場合、フロントエンドは通常の新規接続の時に一般的に送出 される StartupPacket ではなくして CancelRequest メッセージを postmaster に送り、 新規接続を開始します。 postmaster はこのリクエストを処理し接続を解除します。 セキュリティ上の理由から、取り消し要求メッセージに対し直接の回答はありません。
A CancelRequest message will be ignored unless it contains the same key data (PID and secret key) passed to the frontend during connection startup. If the request matches the PID and secret key for a currently executing backend, the postmaster signals the backend to abort processing of the current query.
CancelRequest メッセージは、接続開始段階でフロントエンドに送られたのと同一の鍵 データ(PID と秘密鍵)を含んでいない場合無視されます。現在バックエンドが実行中の 処理に対しする PID と秘密鍵がリクエストと一致した場合、 postmaster はバックエン ドに対し現在の問い合わせ処理の中止を警告します。
The cancellation signal may or may not have any effect --- for example, if it arrives after the backend has finished processing the query, then it will have no effect. If the cancellation is effective, it results in the current command being terminated early with an error message.
取り消しの警告は何の効果も生まないことがあります。たとえば、バックエンドが問い 合わせの処理を完了した後に届いた場合、効果がありません。もし取り消し命令が有効 であれば、エラーメッセージとともに、現在の命令も終了されます。
The upshot of all this is that for reasons of both security and efficiency, the frontend has no direct way to tell whether a cancel request has succeeded. It must continue to wait for the backend to respond to the query. Issuing a cancel simply improves the odds that the current query will finish soon, and improves the odds that it will fail with an error message instead of succeeding.
セキュリティと効率性の理由によるこれらの結論として、フロントエンドは取り消しリク エストが受け付けられたかどうかを知る方法が無いと言うことです。フロントエンドは バックエンドからの問い合わせの回答を待ち続けなければなりません。取り消しを要求 することは単に現在の問い合わせを早めに終らせ、成功ではなくエラーメッセージを出し て不成功とする可能性を多少高める程度です。
Since the cancel request is sent to the postmaster and not across the regular frontend/backend communication link, it is possible for the cancel request to be issued by any process, not just the frontend whose query is to be canceled. This may have some benefits of flexibility in building multiple-process applications. It also introduces a security risk, in that unauthorized persons might try to cancel queries. The security risk is addressed by requiring a dynamically generated secret key to be supplied in cancel requests.
取り消しリクエストは、通常のフロントエンドとバックエンドの通信接続を通してで はなく postmaster に送られるため、その問い合わせが取り消されるフロントエンド だけでなくどんなプロセスによっても出される可能性があります。このことはマルチ 処理アプリケーションを作るに当たって柔軟性を提供します。同時に、承認されてい ない者が問い合わせを取り消そうとするといったセキュリティ上のリスクも持ち込みます。 セキュリティ上のリスクは取り消しリクエストの際に供給される動的に生成される秘密鍵 を要求することによって回避されます。
The normal, graceful termination procedure is that the frontend sends a Terminate message and immediately closes the connection. On receipt of the message, the backend immediately closes the connection and terminates.
通常の洗練された終了手順はフロントエンドが Terminate メッセージを出し、すぐに 接続を閉じることです。メッセージを受け取るとすぐにバックエンドは接続を閉じ終了 します。
An ungraceful termination may occur due to software failure (i.e., core dump) at either end. If either frontend or backend sees an unexpected closure of the connection, it should clean up and terminate. The frontend has the option of launching a new backend by recontacting the postmaster, if it doesn't want to terminate itself.
洗練されていない終了はどちらかの側のソフトウエアの失敗(例えばコアダンプ)によって 起こることがあります。フロントエンドかバックエンドいずれかが予期しない接続の中断 を検知した時、問題を片付けて終了しなくてはなりません。フロントエンドはもし自身が 終了を望まない場合、 postmaster に再交信し新規のバックエンドを立ち上げる選択権を 持っています。