| Postgresql 9.3.25 문서 | ||||
|---|---|---|---|---|
| 이전 | 배트맨 토토 : 문서 : 9.3 : Frontend/백엔드 프로토콜 | 48 장. 프론트 엔드/백엔드 프로토콜 | PostgreSQL : 문서 : 9.3 : 토토 사이트 복제 프로토콜 | |
이 섹션은 토토 사이트 흐름과 의미를 설명합니다. 각 토토 사이트 유형. (각각의 정확한 표현에 대한 세부 사항 토토 사이트가 나타납니다PostgreSQL : 문서 : 9.3 : 사설 토토 형식.)에 따라 몇 가지 다른 서브 프로토콜이 있습니다 연결 상태 : 시작, 쿼리, 기능 호출,COPY및 종료. 또한 있습니다 비동기 운영을위한 특별 조항 (포함 알림 응답 및 명령 취소) 시작 단계 후 언제든지.
세션을 시작하려면 프론트 엔드가 서버에 대한 연결을 엽니 다. 시작 토토 사이트를 보냅니다. 이 토토 사이트에는 이름이 포함됩니다 사용자가 연결하려는 사용자 및 데이터베이스; 또한 사용할 특정 프로토콜 버전을 식별합니다. (선택적으로, 시작 토토 사이트에는 런타임에 대한 추가 설정이 포함될 수 있습니다 매개 변수.) 서버는이 정보와 내용을 사용합니다. 구성 파일의 (예 :pg_hba.conf) 연결이 있는지 여부를 결정합니다 잠정적으로 수용 가능하며 추가 인증이 무엇인지 필수 (있는 경우).
서버는 적절한 인증 요청을 보냅니다 프론트 엔드가 적절한 인증 응답 토토 사이트 (예 : 비밀번호). 모두를 위해 GSSAPI 및 SSPI를 제외한 인증 방법은 최대 1 개가 있습니다. 요청 및 하나의 응답. 어떤 방법에서는 전혀 응답이 없습니다 프론트 엔드에서 필요하므로 인증 요청이 발생하지 않습니다. GSSAPI 및 SSPI의 경우 여러 패킷 교환이 필요할 수 있습니다. 인증을 완료하십시오.
인증주기는 서버가 거부하면서 끝납니다 연결 시도 (ErrorResponse) 또는 전송 Authenticationok.
이 단계에서 서버의 가능한 메시지는 다음과 같습니다.
연결 시도가 거부되었습니다. 그러면 서버 즉시 연결을 닫습니다.
인증 교환이 성공적으로 완료되었습니다.
Frontend는 이제 Kerberos v5 인증에 참여해야합니다. 대화 상자 (여기에 설명되지 않음, Kerberos 사양의 일부) 서버와 함께. 이것이 성공하면 서버가 an으로 응답합니다 Authenticationok, 그렇지 않으면 ErrorResponse로 응답합니다.
Frontend는 이제 포함 된 암호 메드를 보내야합니다 명확한 텍스트 형식의 비밀번호. 이것이 올바른 비밀번호라면 서버는 Authenticationok으로 응답합니다. 그렇지 않으면 응답합니다 ErrorResponse와 함께.
Frontend는 이제 포함 된 PasswordMessage를 보내야합니다
MD5를 통해 암호화 된 비밀번호 (사용자 이름 포함)를 다시 암호화했습니다
에 지정된 4 바이트 랜덤 소금 사용
AuthenticationMd5password 메시지. 이것이 올바른 비밀번호라면
서버는 Authenticationok으로 응답합니다. 그렇지 않으면 응답합니다
ErrorResponse와 함께. 실제 PasswordMessage를 계산할 수 있습니다
sql asconcat ( 'md5',
MD5 (CONCAT (MD5 (COCAT (암호, 사용자 이름)), Random-SALT)).
(명심하십시오md5 ()함수
결과를 16 진수로 반환합니다.)
이 응답은 로컬 유닉스 도메인 연결에만 가능합니다 SCM 자격 증명 메시지를 지원하는 플랫폼에서. 프론트 엔드 SCM 자격 증명 메시지를 발행 한 다음 단일 데이터를 보내야합니다. 바이트. (데이터 바이트의 내용은 흥미롭지 않습니다. 서버가 자격 증명 메시지.) 자격 증명이 허용되는 경우 서버 Authenticationok으로 응답하고 그렇지 않으면 응답합니다 ErrorResponse. (이 메시지 유형은 Pre-9.1에 의해서만 발행됩니다 서버. 결국 프로토콜에서 제거 될 수 있습니다 사양.)
프론트 엔드는 이제 GSSAPI 협상을 시작해야합니다. 그만큼 프론트 엔드는 이에 대한 응답으로 GSSAPI 데이터 스트림. 추가 토토 사이트 인 경우 필수, 서버는 AuthenticationGsScontinue로 응답합니다.
프론트 엔드는 이제 SSPI 협상을 시작해야합니다. 프론트 엔드 SSPI 데이터의 첫 번째 부분과 함께 PasswordMessage를 보냅니다. 이에 대한 응답으로 스트림. 추가 토토 사이트가 필요한 경우 서버는 AuthenticationgsScontinue로 응답합니다.
이 메시지는 이전 단계의 응답 데이터를 포함합니다. GSSAPI 또는 SSPI 협상 (AuthenticationGSS, AuthenticationsSpi 또는 이전 AuthenticationGsScontinue). 만약 이 메시지의 GSSAPI 또는 SSPI 데이터는 더 많은 데이터가 필요하다는 것을 나타냅니다. 인증을 완료하려면 프론트 엔드는 해당 데이터를 다음과 같이 보내야합니다. 다른 passwordMessage. GSSAPI 또는 SSPI 인증 인 경우 이 메시지에 의해 완료되면 서버는 다음으로 보내집니다 성공적인 인증을 나타내는 인증 또는 실패를 나타내는 ErrorResponse.
서버가 요청 된 마이너 프로토콜 버전을 지원하지 않습니다. 클라이언트는 이전 버전의 프로토콜을 지원합니다. 이 메시지는 지원되는 최고 마이너 버전을 나타냅니다. 이것 클라이언트가 지원하지 않은 경우 메시지가 전송됩니다. 프로토콜 옵션 (예 :_PQ_.) 시작 패킷에서. 이 메시지가 될 것입니다 그 다음에 오류 응답 또는 성공을 나타내는 메시지가 인증 실패.
프론트 엔드가 인증 방법을 지원하지 않는 경우 서버에서 요청한 다음 즉시 닫아야합니다. 연결.
Authenticationok을받은 후 프론트 엔드는 기다려야합니다 서버의 추가 메시지. 이 단계에서 백엔드 프로세스가 시작되고 있으며 프론트 엔드는 단지 관심이 있습니다. 방관자. 스타트 업 시도가 실패하는 것은 여전히 가능합니다. (ErrorResponse) 또는 요청 된 지원을 거부하는 서버 마이너 프로토콜 버전 (협상) 일반적인 경우 백엔드는 일부 Parameterstatus 메시지를 보냅니다. BackendkeyData 및 마지막으로 ReadyForquery.
이 단계에서 백엔드는 어떤 적용을 적용하려고 시도합니다. 추가 런타임 매개 변수 설정에 제공된 추가 런타임 매개 변수 설정 시작 메시지. 성공하면 이러한 값은 세션이됩니다 기본값. 오류는 ErrorResponse 및 종료를 유발합니다.
이 단계의 백엔드의 가능한 메시지는 다음과 같습니다.
이 토토 사이트는 프론트 엔드가 해야하는 비밀 키 데이터를 제공합니다 나중에 취소 요청을 발행하려면 저장하십시오. 그만큼 프론트 엔드는이 토토 사이트에 응답해서는 안되지만 계속해야합니다. ReadyForquery 토토 사이트 듣기.
이 메시지는 현재 (이니셜)에 대한 프론트 엔드를 알려줍니다. 와 같은 백엔드 매개 변수 설정client_encoding또는Datestyle. 그만큼 프론트 엔드는이 토토 사이트를 무시하거나 해당 토토 사이트 설정을 기록 할 수 있습니다. 향후 사용; 보다섹션 48.2.6자세한 내용은. 프론트 엔드는 응답해서는 안됩니다 이 토토 사이트이지만 Readyforquery를 계속 듣고 있습니다 토토 사이트.
스타트 업이 완료되었습니다. 프론트 엔드는 이제 명령을 발행 할 수 있습니다.
스타트 업 실패. 이걸 보내 후 연결이 닫힙니다 토토 사이트.
경고 메시지가 발행되었습니다. 프론트 엔드가 표시되어야합니다 메시지이지만 ReadyForquery를 계속 듣습니다 ErrorResponse.
ReadyForquery 메시지는 백엔드가 동일합니다. 각 명령주기 후 문제. 코딩 요구에 따라 프론트 엔드, readyforquery를 고려하는 것이 합리적입니다 명령주기 시작 또는 ReadyForquery를 결말로 고려합니다. 시작 단계 및 각 후속 명령주기.
간단한 쿼리주기는 프론트 엔드를 통해 시작됩니다. 백엔드에 대한 쿼리 메시지. 메시지에는 SQL 명령이 포함됩니다 (또는 명령) 텍스트 문자열로 표현됩니다. 그런 다음 백엔드가 보냅니다 내용에 따라 하나 이상의 응답 메시지 쿼리 명령 문자열 및 마지막으로 ReadyForquery 응답 메시지입니다. ReadyForquery는 프론트 엔드에게 새를 안전하게 보낼 수 있음을 알려줍니다. 명령. (실제로 프론트 엔드가 기다릴 필요는 없습니다. 다른 명령을 발행하기 전에 readyforquery 그러나 프론트 엔드는해야합니다 그런 다음 이전 명령이 실패하고 이미 발행 된 후에 발행됩니다 성공.)
백엔드의 가능한 응답 메시지는 다음과 같습니다.
정상적으로 완료된 SQL 명령.
백엔드는 프론트 엔드에서 테이블로 데이터를 복사 할 준비가되었습니다. 보다섹션 48.2.5.
백엔드는 테이블에서 프론트 엔드로 데이터를 복사 할 준비가되었습니다. 보다섹션 48.2.5.
A에 대한 응답으로 행이 반환 될 것을 나타냅니다select, Fetch, 등 쿼리. 이 토토 사이트의 내용은 열 레이아웃을 설명합니다 줄의. 이어서 각각에 대한 Datarow 토토 사이트가 이어집니다. 줄이 프론트 엔드로 돌아 오는 행.
a에 의해 반환 된 행 세트 중 하나입니다.select, Fetch등 질문.
빈 쿼리 문자열이 인식되었습니다.
오류가 발생했습니다.
쿼리 문자열의 처리가 완료되었습니다. 별도의 메시지 쿼리 문자열에 여러 SQL 명령. (CommandComplete는 처리 종료를 표시합니다 전체 문자열이 아닌 하나의 SQL 명령.) ReadyForquery는 항상 처리가 성공적으로 종료되었는지 여부에 관계없이 전송됩니다 오류.
쿼리와 관련하여 경고 토토 사이트가 발행되었습니다. 통지는 다른 응답에 추가됩니다. 즉, 백엔드는 명령을 계속 처리합니다.
A에 대한 응답select쿼리 (또는 와 같은 행을 반환하는 다른 쿼리설명또는show) 일반적으로 rowdescription, 0 이상의 Datarow 메시지로 구성된 다음 CommandComplete.COPY에서 또는 프론트 엔드에 설명 된대로 특수 프로토콜을 호출합니다섹션 48.2.5. 다른 모든 것 쿼리 유형은 일반적으로 CommandComplete 메시지 만 생성합니다.
쿼리 문자열에는 여러 쿼리를 포함 할 수 있으므로 세미콜론), 이전에 그러한 반응 시퀀스가 몇 가지있을 수 있습니다 백엔드는 쿼리 문자열을 처리합니다. ReadyForquery입니다 전체 문자열이 처리되었고 백엔드가 새 쿼리 문자열을 수락 할 준비가되었습니다.
완전히 비어있는 경우 (공백 이외의 내용 없음) 쿼리 문자열이 수신되고 응답은 emptyQueryResponse 다음이 뒤 따릅니다 readyforquery.
오류가 발생하면 ErrorResponse가 발행 다음 ReadyForquery. 쿼리 문자열의 모든 추가 처리는 다음과 같습니다 ErrorResponse에 의해 중단됩니다 (더 많은 쿼리가 남아 있더라도). 이것은 메시지 순서를 통해 부분적으로 발생할 수 있습니다. 개별 쿼리에 의해 생성됩니다.
간단한 쿼리 모드에서 검색된 값의 형식은 항상입니다. 주어진 명령이 a를 제외하고 텍스트fetchBINAGE옵션. 이 경우 검색된 값 이진 형식입니다. rowdescription에 주어진 형식 코드 토토 사이트는 어떤 형식이 사용되고 있는지 알려줍니다.
ErrorResponse를 수락하기 위해 프론트 엔드를 준비해야합니다 다른 유형의 다른 유형을 예상 할 때마다 aliceresponse 메시지 메시지. 참조 참조섹션 48.2.6외부 이벤트로 인해 백엔드가 생성 될 수있는 토토 사이트
권장되는 관행은 State-Machine의 Frontendend를 코딩하는 것입니다 언제든지 모든 토토 사이트 유형을 허용하는 스타일 정확한 가정에 대한 배선보다는 말이됩니다. 일련의 토토 사이트.
확장 쿼리 프로토콜은 위에서 설명한 것을 분해합니다 여러 단계로 간단한 쿼리 프로토콜. 결과 개선을 위해 준비 단계를 여러 번 재사용 할 수 있습니다 능률. 또한 추가 기능과 같은 추가 기능이 있습니다 데이터 값을 별도의 매개 변수로 공급할 가능성 쿼리 문자열에 직접 삽입하는 대신
확장 프로토콜에서 프론트 엔드는 먼저 구문 분석을 보냅니다. 텍스트 쿼리 문자열이 포함 된 메시지는 선택적으로 일부입니다 매개 변수 자리 표시 자의 데이터 유형에 대한 정보 대상 준비 대상 개체의 이름 (빈 문자열 이름이없는 준비된 진술을 선택합니다). 응답도 마찬가지입니다 parsecomplete 또는 ErrorResponse. 매개 변수 데이터 유형은 될 수 있습니다 OID에 의해 지정; 주어지지 않으면, 파서는 추론을 시도합니다 비 유형의 리터럴과 같은 방식으로 데이터 유형 문자열 상수.
참고 :매개 변수 데이터 유형은 지정되지 않은 상태로 남겨 둘 수 있습니다 0으로 설정하거나 매개 변수 유형 OID 배열을 만들어 매개 변수 기호 수보다 짧습니다 ($n)에서 사용됩니다 쿼리 문자열. 또 다른 특별한 경우는 매개 변수 유형이 할 수 있다는 것입니다 로 지정됩니다.void(즉,의 OIDvoidPseudotype). 이것은 허용하기위한 것입니다 함수 매개 변수에 사용할 매개 변수 기호 실제로 매개 변수. 일반적으로 a의 맥락은 없습니다.void매개 변수를 사용할 수 있지만 그러한 경우 매개 변수 기호는 함수의 매개 변수 목록에 나타납니다. 효과적으로 무시했습니다. 예를 들어,와 같은 함수 호출foo ($ 1, $ 2, $ 3, $ 4)함수와 일치 할 수 있습니다 2 인치와 두 개의 아웃 논쟁이있는 경우$ 3및$ 4유형이있는 것으로 지정됩니다void.
참고 :구문 분석 메시지에 포함 된 쿼리 문자열 둘 이상의 SQL 문을 포함 할 수 없습니다. 그렇지 않으면 구문 오류입니다 보고 된. 이 제한은 단순한 정체에 존재하지 않습니다 프로토콜이지만 확장 프로토콜에 존재합니다. 준비된 진술 또는 포털에 여러 가지를 포함하도록 허용합니다 명령은 프로토콜을 과도하게 복잡하게 만듭니다.
성공적으로 작성된 경우 명명 된 준비된 개체가 지속됩니다 현재 세션이 끝날 때까지 명시 적으로 파괴되지 않는 한. 이름이없는 준비된 진술은 다음 구문 분석까지 지속됩니다. 명령문은 이름이없는 진술을 대상으로 지정합니다 발행. (간단한 쿼리 메시지는 이름이없는 것을 파괴합니다. 진술.) 명명 된 명령문은 명시 적으로 닫아야합니다 다른 구문 분석 메시지로 재정의되기 전에 이름이없는 진술에는 필요하지 않습니다. 준비된 진술 SQL 명령 레벨에서 생성 및 액세스 할 수 있습니다.준비andexecute.
준비된 진술이 있으면 다시 확인할 수 있습니다. 바인드 메시지를 사용하여 실행. 바인드 메시지는 이름을 제공합니다 소스 준비 된 문 (빈 문자열은 이름이없는 것을 나타냅니다 준비된 문), 대상 포털의 이름 (빈 문자열은 이름이없는 포털을 나타냅니다.) 준비된 진술서에있는 매개 변수 자리 소유자. 그만큼 제공된 매개 변수 세트는 준비된 것과 일치해야합니다. 성명. (당신이 선언 한 경우void구문 분석 메시지의 매개 변수는 바인드 메시지.) BAND는 또한 모든 데이터에 사용할 형식을 지정합니다. 쿼리에 의해 반환; 형식은 전체적으로 지정할 수 있습니다 콜럼 당. 응답은 bindcomplete 또는입니다 ErrorResponse.
참고 :텍스트와 이진 출력 사이의 선택은 다음과 같습니다 SQL에 관계없이 BAND에 주어진 형식 코드에 의해 결정됩니다. 관련 명령. 그만큼BINAGE속성 확장 쿼리를 사용할 때 커서 선언은 관련이 없습니다 규약.
쿼리 계획은 일반적으로 바인드 메시지가있을 때 발생합니다 가공. 준비된 명령문에 매개 변수가없는 경우 반복적으로 실행되면 서버는 생성 된 계획을 저장하고 동일한 준비가 된 후 후속 바인드 메시지 중에 재사용하십시오. 성명. 그러나 일반적인 계획보다 훨씬 덜 효율적이지 않은 계획을 만들 수 있습니다. 이는 제공된 특정 매개 변수 값에 따라 다릅니다. 이것 프로토콜에 관한 한 투명하게 발생합니다.
성공적으로 생성되면, 이름이 지정된 포털 개체는 명시 적으로 파괴되지 않는 한, 현재 거래 종료. an 이름이없는 포털은 거래 종료시 또는 이름이없는 포털을 목적지가 발행됩니다. (간단한 쿼리 메시지도 마찬가지입니다 이름이없는 포털을 파괴합니다.) 이름이 지정된 포털은 명시 적으로 있어야합니다 다른 바인딩 메시지로 재정의되기 전에 닫혔지만 이름없는 포털에는 필요하지 않습니다. 이름이 지정된 포털도 할 수 있습니다 SQL 명령 수준에서 생성 및 액세스를 사용하여커서 선언및fetch.
포털이 존재하면 Execute를 사용하여 실행할 수 있습니다. 토토 사이트. 실행 토토 사이트는 포털 이름을 지정합니다 (빈 문자열은 이름이없는 포털을 나타냅니다)와 최대 결과 행 수를 나타냅니다. (제로 의미"모든 행을 가져 오십시오"). 그만큼 결과 행 카운트는 명령을 포함하는 포털에서만 의미가 있습니다 그 리턴 행 세트; 다른 경우에는 명령이 항상 실행됩니다 완료하면 행 카운트가 무시됩니다. 가능한 응답 실행하려면 발행 된 쿼리에 대해 위에서 설명한 것과 동일합니다. 실행이 발생하지 않는 경우를 제외하고는 간단한 쿼리 프로토콜을 통해 readyforquery 또는 rowdescription이 발행됩니다.
execute가 a의 실행을 완료하기 전에 종료되는 경우 포털 (0이 아닌 결과 열 수에 도달하면 포털 서브 된 메시지; 이 메시지의 모양은 다른 처형이 동일하게 발행되어야하는 프론트 엔드 포털 작업을 완료합니다. CommandComplete 메시지 소스 SQL 명령의 완료를 나타내는 것은 전송되지 않습니다. 포털의 실행이 완료되었습니다. 따라서 실행 단계는입니다 이 중 정확히 하나의 모양으로 항상 종료됩니다. 메시지 : CommandComplete, VolitQueryResponse (포털이있는 경우 빈 쿼리 문자열에서 생성), ErrorResponse, Or 포털 서식.
각 시리즈의 확장 쿼리 메시지를 완성 할 때 프론트 엔드는 동기화 메시지를 발행해야합니다. 이 매개 변수가없는 메시지 백엔드가 현재 트랜잭션이 아닌 경우 현재 트랜잭션을 종료하게합니다. 내부시작/커밋트랜잭션 블록 ("Close"오류가 없으면 커밋하거나 롤백하는 것을 의미합니다 오류 인 경우). 그런 다음 ReadyForquery 응답이 발행됩니다. 의 목적 동기화는 오류 복구를위한 재 동기화 지점을 제공하는 것입니다. 확장 쿼리를 처리하는 동안 오류가 감지 된 경우 메시지, 백엔드는 ErrorResponse를 발행 한 다음 읽고 폐기합니다 동기화에 도달 할 때까지 메시지를 보낸 다음 ReadyForquery를 발행하고 일반 메시지 처리로 돌아갑니다. (그러나 건너 뛰지 않아도됩니다 오류가 감지되면 발생합니다while처리 동기화 - 이렇게합니다 각각에 대해 하나의 readyforquery만이 있습니다. 동조.)
참고 :동기화는로 열린 트랜잭션 블록을 유발하지 않습니다.시작닫히십시오. 가능합니다 ReadyForquery 메시지에는 포함 되므로이 상황을 감지하십시오 거래 상태 정보.
이러한 기본, 필요한 작업 외에도 있습니다 확장 쿼리와 함께 사용할 수있는 여러 선택적 작업 규약.
설명 메시지 (포털 변형) 이름을 지정합니다. 기존 포털 (또는 이름없는 포털의 빈 문자열). 그만큼 응답은 포털을 실행하여 반환됩니다. 또는 인 경우 nodata 메시지 포털에는 행을 반환하는 쿼리가 포함되어 있지 않습니다. 또는 그러한 포털이없는 경우 ErrorResponse.
설명 메시지 (Statement)는 이름을 지정합니다 기존 준비 된 명령문 (또는 이름이없는 빈 문자열 준비된 진술). 응답은 ParameterDescription 메시지입니다 진술에 필요한 매개 변수를 설명하고 반환 될 행을 설명하는 RowDescription 메시지 성명서가 결국 실행될 때 (또는 Nodate 메시지 진술은 행을 반환하지 않습니다). ErrorResponse가 다음에 발행됩니다 그러한 준비된 진술은 없습니다. Bind는 그렇지 않기 때문에 주목하십시오 아직 발행되었지만 반환 된 열에 사용될 형식은 다음과 같습니다. 백엔드에는 아직 알려지지 않았습니다. 형식 코드 필드 이 경우 rowdescription 메시지가 제로가됩니다.
팁 :대부분의 시나리오에서 프론트 엔드는 하나 또는 실행을 발급하기 전에 설명의 다른 변형, 결과를 해석하는 방법을 알고 있다는 것은 돌아올 것입니다.
닫기 메시지는 기존 준비 된 진술을 닫습니다 포털 및 릴리스 리소스. 가까이 발행하는 것은 오류가 아닙니다 존재하지 않는 진술 또는 포털 이름에 대해. 응답은입니다 일반적으로 Closecomplete이지만 일부는 ErrorResponse 일 수 있습니다 자원을 공개하는 동안 어려움이 발생합니다. 주목하십시오 준비된 진술을 닫으면 암시 적으로 열린 포털이 닫힙니다 그것은 그 진술에서 구성되었습니다.
플러시 토토 사이트로 인해 특정 출력이 발생하지 않습니다. 생성되었지만 백엔드가 보류중인 데이터를 전달하도록 강요합니다. 출력 버퍼. 플러시는 연장 된 쿼리 후에 보내야합니다 프론트 엔드가 결과를 검사하려는 경우 동기화를 제외한 명령 더 많은 명령을 발행하기 전에 그 명령의. 플러시없이 백엔드가 반환 한 토토 사이트는 최소로 결합됩니다. 네트워크 오버 헤드를 최소화하기위한 가능한 패킷 수.
참고 :간단한 쿼리 메시지는 대략입니다 시리즈 구문 분석, 바인드, 포털 설명, 실행, 실행, 이름이없는 준비된 명령문과 포털을 사용하여 닫고 동기화하십시오 객체 및 매개 변수가 없습니다. 한 가지 차이점은 그것이 받아 들일 것이라는 것입니다 쿼리 문자열의 여러 SQL 문을 자동으로 각각의 바인드/설명/실행 순서를 수행합니다 계승. 또 다른 차이점은 그것이 돌아 오지 않을 것이라는 것입니다 parsecomplete, bindcomplete, closecomplete 또는 nodata 메시지.
함수 호출 서브 프로토콜을 사용하면 클라이언트가 요청할 수 있습니다. 데이터베이스에 존재하는 모든 기능을 직접 호출하십시오PG_PROC시스템 카탈로그. 클라이언트는해야합니다 함수에 대한 권한을 실행하십시오.
참고 :함수 호출 서브 프로토콜은 레거시 기능입니다 그것은 아마도 새로운 코드에서 피하는 것이 가장 좋습니다. 비슷한 결과가 될 수 있습니다 준비된 진술을 설정하여 수행선택 함수 ($ 1, ...). 기능 그런 다음 통화 사이클을 바인드/실행으로 대체 할 수 있습니다.
기능 호출주기는 전면 엔드에 의해 시작됩니다. 백엔드에 대한 기능을하는 메시지. 그런 다음 백엔드는 하나를 보냅니다 함수 결과에 따라 더 많은 응답 메시지 전화를 걸어 마지막으로 ReadyForquery 응답 메시지. ReadyForquery 프론트 엔드에 새 쿼리를 안전하게 보낼 수 있거나 기능 호출.
백엔드의 가능한 응답 메시지는 다음과 같습니다.
오류가 발생했습니다.
함수 호출이 완료되어 결과를 반환했습니다. 토토 사이트. (기능 통화 프로토콜은 처리 할 수 있습니다 행 유형이나 결과 세트가 아닌 단일 스칼라 결과.)
함수 호출 처리가 완료되었습니다. ReadyForquery 처리가 성공적으로 또는 그와 함께 항상 전송됩니다 오류.
함수와 관련하여 경고 토토 사이트가 발행되었습니다. 부르다. 통지는 다른 응답, 즉 백엔드에 추가됩니다. 명령을 계속 처리 할 것입니다.
theCOPY명령은 고속 벌크를 허용합니다 서버로 또는 데이터 전송. 복사 및 복사 각 작업 각각 연결을 고유 한 서브 프로토콜로 전환합니다. 작업이 완료 될 때까지 지속됩니다.
카피인 모드 (서버로의 데이터 전송)가 시작될 때 백엔드가 a 실행됩니다.stdin에서 복사SQL 성명. 백엔드는 CopyInResponse 메시지를 THE에 보냅니다 프론트 엔드. 그런 다음 프론트 엔드는 0 이상의 카피 사다를 보내야합니다 입력 데이터 스트림을 형성하는 메시지. (메시지 경계 행 경계와 관련이 없을 필요는 없으며 그것은 종종 합리적인 선택이지만.) 프론트 엔드는 복사 메시지를 보내서 카피 인 모드를 종료합니다. (성공적인 종료 허용) 또는 CopyFail 메시지 (그렇습니다 원인COPY실패 할 SQL 문 오류). 그런 다음 백엔드는 명령 처리 모드로 되돌아갑니다 이전에COPY시작했습니다 간단하거나 확장 쿼리 프로토콜이됩니다. 다음으로 보내집니다 CommandComplete (성공한 경우) 또는 ErrorResponse (if 아니다).
카피 인 모드에서 백엔드 감지 오류가 발생한 경우 (CopyFail 메시지 수신을 포함하여) 백엔드가 발행됩니다. ErrorResponse 메시지. 인 경우COPY명령은 확장 쿼리 메시지를 통해 발행되었으며 백엔드는 이제 동기화 메시지가 수신 될 때까지 프론트 엔드 메시지를 폐기하십시오. 그런 다음 ReadyForquery를 발행하고 정상 처리로 돌아갑니다. 인 경우COPY명령은 간단하게 발행되었습니다 쿼리 메시지, 그 메시지의 나머지 부분은 폐기되고 ReadyForquery가 발행됩니다. 두 경우 모두 후속 카피 데이터, 프론트 엔드에서 발행 한 Copydone 또는 CopyFail 메시지는 간단히 삭제됩니다.
백엔드는 플러시 및 동기화 메시지를 무시합니다. 복사 모드. 다른 비 코피 메시지 유형의 수신 설명 된대로 카피인 상태를 중단하는 오류를 구성합니다. 위에. (플러시 및 동기화의 예외는 편의를위한 것입니다. 실행 후 항상 플러시 또는 동기화를 보내는 클라이언트 라이브러리 메시지, 실행 될 명령이 A인지 확인하지 않고stdin에서 복사.)
복사 모드 (서버에서 데이터 전송)가 시작됩니다. 백엔드가 a 실행됩니다.stdout에 복사SQL 성명. 백엔드는 copiOUtresponse 메시지를 THE에 보냅니다 Frontend, 그 다음에는 0 이상의 CopyData 메시지가 이어집니다 (항상 하나 행당), 복사기가 뒤 따릅니다. 그런 다음 백엔드는 다시 돌아갑니다 명령 처리 모드 이전에COPY시작하여 CommandComplete를 보냅니다. 그만큼 프론트 엔드는 이전을 중단 할 수 없습니다 (폐쇄를 제외하고는 제외합니다 연결 또는 취소 요청 발급) 그러나 폐기 할 수 있습니다. 원치 않는 카피다타 및 카피 도네 메시지.
카피 아웃 모드에서 백엔드 감지 오류가 발생한 경우, 백엔드는 ErrorResponse 메시지를 발행하고 정상적인 처리. 프론트 엔드는 수령을 처리해야합니다 복사 모드 종료로 ErrorResponse.
eliceResponse 및 Parameterstatus 메시지가 가능합니다 CopyData 메시지 사이에 산재 해지려면; 프론트 엔드는 처리해야합니다 이러한 경우, 다른 비동기 메시지를 위해 준비해야합니다. 유형도 (참조섹션 48.2.6). 그렇지 않으면, CopyData 또는 Copydone 이외의 모든 메시지 유형은 다음과 같이 처리 할 수 있습니다. 복사 모드 종단.
Copy-Both라는 다른 카피 관련 모드가 있습니다 고속 벌크 데이터 전송 허용and서버에서. 카피 모드 Walsender 모드의 백엔드가 A를 실행할 때 시작됩니다.start_replication진술. 백엔드는 a 프론트 엔드에 대한 CoppyBothResponse 메시지. 백엔드와 Frontend는 양쪽 끝이 보낼 때까지 CopyData 메시지를 보낼 수 있습니다 복사 메시지. 클라이언트가 복사 메시지를 보낸 후 연결은 복사기 모드에서 카피 아웃 모드로 이동합니다. 클라이언트는 더 이상 CopyData 메시지를 보낼 수 없습니다. 마찬가지로 서버는 복사 메시지를 보냅니다. 모드 및 서버는 더 이상 CopyData 메시지를 보내지 않을 수 있습니다. 후에 양측은 복사 메시지를 보냈습니다. 복사 모드는 종료되고 백엔드는 명령 처리 모드로 되돌아갑니다. 카피-볼 때 백엔드 감지 오류가 발생한 경우 백엔드는 ErrorResponse 메시지를 발행하고 Frontend를 버립니다 동기화 메시지가 수신 될 때까지 메시지를 작성한 다음 readyforquery 및 정상 처리로 돌아갑니다. 프론트 엔드 ErrorResponse의 수신을 둘 다에서 사본을 종료하는 것으로 처리하십시오. 지도; 이 경우 복사를 보내지 않아야합니다. 보다섹션 48.3자세한 내용 카피 모드를 통해 전송 된 서브 프로토콜에서.
CopyInResponse, CopyOUTRESPONSE 및 COPYBOTHREPONSE 메시지에는 숫자에 대한 프론트 엔드를 알려주는 필드가 포함됩니다. 행당 열 및 각 열에 사용되는 형식 코드. (현재 구현 시점에서 주어진 모든 열COPY작동은 동일한 형식을 사용합니다. 그러나 메시지 디자인은 이것을 가정하지 않습니다.)
백엔드가 메시지를 보내는 몇 가지 사례가 있습니다. 이는 프론트 엔드의 명령에 의해 구체적으로 촉발되지 않습니다 개울. 이러한 메시지를 처리 할 준비가되어 있어야합니다. 언제든지 쿼리에 참여하지 않더라도. 최소한, 하나입니다 쿼리를 읽기 전에 이러한 사례를 확인하십시오. 응답.
eliceResponse 토토 사이트가 생성 될 수 있습니다. 외부 활동에; 예를 들어, 데이터베이스 관리자 인 경우 명령 a"빠른"데이터베이스 종료, 백엔드는 이전 에이 사실을 나타내는 주석 반응을 보냅니다 연결을 닫습니다. 따라서, 정면 엔드는 항상 있어야합니다 언제라도 주도적 인 응답 메시지를 수락하고 표시 할 준비가되었습니다 연결은 명목상 유휴 상태입니다.
Parameterstatus 메시지는 활성화 될 때마다 생성됩니다 백엔드가 믿는 매개 변수에 대한 값 변경 프론트 엔드는 알아야합니다. 가장 일반적으로 이것은 응답으로 발생합니다SETSQL 명령에 의해 실행되었습니다 frontend, and this case is effectively synchronous — but it is also 매개 변수 상태 변경이 발생할 수 있습니다 관리자는 구성 파일을 변경 한 다음를 보냈습니다.Sighup서버에 신호를 보냅니다. 또한, aSET명령이 롤백됩니다 적절한 Parameterstatus 메시지가 생성되어보고합니다 현재 유효 가치.
현재에는 하드 유선 매개 변수 세트가 있습니다. Parameterstatus가 생성 될 것입니다.server_version, Server_encoding, client_encoding, Application_Name, is_superuser, Session_Authorization, Datestyle, IntervalStyle, TimeZone, integer_datetimes및Standard_Conforming_strings. (Server_encoding, TimeZone, 그리고integer_datetimes8.0 이전에 출시;Standard_Conforming_strings8.1 이전에 출시;IntervalStyle그렇지 않았습니다 8.4 이전에 릴리스에 의해보고;application_name이전에 릴리스에 의해보고되지 않았습니다 9.0.) 참고Server_version, Server_encoding및integer_dateTimes할 수없는 의사 파라미터입니다 시작 후 변경하십시오. 이 세트는 미래에 또는 심지어 변경 될 수 있습니다 구성 가능하게됩니다. 따라서 프론트 엔드는 단순히 무시해야합니다 이해하지 못하거나 관리하는 매개 변수에 대한 Parameterstatus 에 대한.
프론트 엔드가 a 발행하는 경우듣기명령, 그러면 백엔드는 NotificationResponse 토토 사이트를 보냅니다 ( 냉담한 반응과 혼동하십시오!) a 때마다Notify동일한 채널에 대해 명령이 실행됩니다 이름.
참고 :현재, NotificationResponse 만 보낼 수 있습니다 거래 외부에서는 명령-응답 시리즈이지만 직전에 발생할 수 있습니다 ReadyForquery. 가정하는 프론트 엔드 로직을 설계하는 것은 현명하지 않습니다 그러나 그게. 모범 사례는 받아 들일 수있는 것입니다 프로토콜의 어느 시점에서나 NotificationResponse.
쿼리 처리 중에 프론트 엔드가 요청할 수 있습니다. 쿼리 취소. 취소 요청은 직접 전송되지 않습니다 구현 이유로 백엔드에 대한 공개 연결 효율성 : 우리는 지속적으로 백엔드를 확인하고 싶지 않습니다. 쿼리 처리 중에 프론트 엔드의 새로운 입력. 취소 요청은 상대적으로 드물게되어야하므로 우리는 그것들을 약간 만듭니다. 정상적인 경우 페널티를 피하기 위해 번거로운.
취소 요청을 발행하려면 Frontend가 새로운 연결을 엽니 다. 서버에 그리고 일반적으로 새로운 것을 통해 발송 될 startupmessage 메시지 연결. 서버는이 요청을 처리 한 다음 연결. 보안상의 이유로 요청 메시지 취소.
ConcelRequest 메시지가 포함되지 않으면 무시됩니다. 동일한 키 데이터 (PID 및 Secret Key)가 전면에 전달되었습니다. 연결 시작. 요청이 PID 및 비밀 키와 일치하는 경우 현재 실행중인 백엔드의 경우 현재의 처리 쿼리가 중단되었습니다. (기존 구현에서는 이에 의해 수행됩니다 처리중인 백엔드 프로세스에 특수 신호 보내기 쿼리.)
취소 신호는 어떤 영향을 미치지 않을 수도 있습니다. 예를 들어, 백엔드가 처리가 완료된 후에 도착하면 쿼리는 효과가 없습니다. 취소가있는 경우 효과적으로, 현재 명령이 조기에 종료됩니다. 오류 메시지와 함께.
이 모든 것의 결과는 보안과 효율성, 프론트 엔드는 취소 여부를 알 수있는 직접적인 방법이 없습니다. 요청이 성공했습니다. 백엔드가 계속 기다려야합니다 쿼리에 응답하십시오. 취소를 발행하면 단순히 확률이 향상됩니다 현재 쿼리가 곧 완료 될 것이며 성공 대신 오류 메시지로 실패합니다.
취소 요청이 새 연결을 통해 전송되기 때문에 정기적 인 프론트 엔드/백엔드 커뮤니케이션에서 서버가 아닙니다 링크, 취소 요청을 발행 할 수 있습니다. 쿼리가 취소 될 프론트 엔드뿐만 아니라 프로세스. 이것 다중 프로세스를 구축 할 때 추가 유연성을 제공 할 수 있습니다 응용 프로그램. 또한 보안 위험을 소개합니다 무단 사람은 쿼리를 취소하려고 할 수 있습니다. 보안 위험 동적으로 생성 된 비밀 키를 요구하여 해결됩니다. 취소 요청에 제공됩니다.
정상적이고 우아한 종료 절차는 정면 엔드입니다 종료 토토 사이트를 보내고 즉시 연결을 닫습니다. ~에 이 토토 사이트를받은 백엔드는 연결을 닫고 종료.
드문 경우 (예 : 관리자-명령 데이터베이스와 같은 종료) 백엔드는 프론트 엔드 요청없이 연결을 끊을 수 있습니다 그렇게하려면. 그러한 경우 백엔드는 오류를 보내려고합니다. 또는 그 전에 연결이 끊어진 이유를주는 메시지에 주목하십시오. 연결을 닫습니다.
다른 종료 시나리오는 다양한 실패 사례에서 발생합니다. 한쪽 끝 또는 다른 쪽의 코어 덤프와 같은 커뮤니케이션 링크, 메시지 바탕리 동기화 손실 등 프론트 엔드 또는 백엔드가 예기치 않은 폐쇄를 보는 경우 연결하면 정리하고 종료해야합니다. 프론트 엔드는 있습니다 서버를 다시 접촉하여 새 백엔드를 시작하는 옵션 스스로 종료하고 싶지 않습니다. 연결을 닫는 것도 마찬가지입니다 인식 할 수없는 메시지 유형이 수신되면 권장됩니다. 아마도 메시지-사운드 동기 손실을 나타냅니다.
정상 또는 비정상 종료의 경우 공개 거래 커밋되지 않고 롤백됩니다. 그러나 a 프론트 엔드는 끊어지는 동안select쿼리가 처리 중이며 백엔드는 아마도 단절을 알기 전에 쿼리. 쿼리가 외부에있는 경우 모든 트랜잭션 블록 (시작 ... 커밋시퀀스) 그러면 결과 일 수 있습니다 단절이 인식되기 전에 커밋되었습니다.
ifPostgreSQLSSL지원, 프론트 엔드/백엔드 커뮤니케이션은를 사용하여 암호화 할 수 있습니다.SSL. 이것은 통신 보안을 제공합니다 공격자가 세션을 캡처 할 수있는 환경 교통. 암호화에 대한 자세한 내용은PostgreSQL세션SSL, 참조섹션 17.9.
시작하려면SSL암호화 연결, 프론트 엔드는 처음에 sslrequest 메시지를 보냅니다 스타트 업즈 대신. 그런 다음 서버는 a로 응답합니다 단일 바이트 포함S또는n공연하다SSL50035_50166S, 수행SSL스타트 업 핸드 셰이크 (여기에 설명되지 않음,SSL사양) 서버와 함께. 이것이 있다면 성공적으로, 일반적인 스타트 업무를 계속 보내십시오. 이것에서 SARTUPMESSAGE 및 모든 후속 데이터가입니다.SSL-암호화. 계속하려면n, 일반적인 startupmessage를 보내십시오 암호화없이 진행하십시오.
프론트 엔드도 errormessage를 처리 할 준비를해야합니다. 서버에서 sslrequest에 대한 응답. 이것은 경우에만 발생합니다 서버는 추가를 선행합니다SSL지원PostgreSQL. (그러한 서버는 이제 매우 있습니다 고대, 아마도 더 이상 야생에 존재하지 않을 것입니다.)이 경우 연결은 닫아야하지만 프론트 엔드는 새로운 연결을 열고 요청하지 않고 진행하십시오SSL.
초기 sslRequest는 다음과 같은 연결에 사용할 수 있습니다. CancelRequest 메시지를 보내기 위해 열려 있습니다.
프로토콜 자체가 서버에 대한 방법을 제공하지는 않지만 강제SSL암호화, the 관리자는 암호화되지 않은 거부하도록 서버를 구성 할 수 있습니다 인증 검사의 부산물로서의 세션.