| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
PREPARE TRANSACTION는 2상 커밋으로 현재의 트랜잭션(transaction)를 준비합니다. 이 명령의 뒤 트랜잭션(transaction)는 현재의 세션과 관련하지 않게 됩니다. 트랜잭션(transaction) 상태는 완전하게 디스크상에 보존되어 커밋 요구전에 데이터베이스가 크래쉬 해 버렸다고 해도, 거의 확실히 정상적으로 커밋할 수 있게 됩니다.
준비된 후, 그 트랜잭션(transaction)를 COMMIT PREPARED 이나 ROLLBACK PREPARED 에 의해 커밋 또는 롤백(rollback) 할 수가 있습니다. 원래의 트랜잭션(transaction)를 실행한 세션 만이 아니고, 어느 세션로부터 이러한 명령을 발행할 수가 있습니다.
명령을 발행한 세션으로부터 보면 PREPARE TRANSACTION는 ROLLBACK명령와 다른 거이 아닙니다. 그것을 실행한 후, 실행중의 현재의 실행되는 트랜잭션(transaction)는 없어지고 준비한 트랜잭션(transaction)의 효과는 더이상 가시화 되지 않습니다. (그 트랜잭션(transaction)가 커밋되었을 경우에 효과가 가시가 됩니다. )
어떠한 원인으로PREPARE TRANSACTION명령이 실패했을 경우,ROLLBACK를 합니다. 즉, 현재의 트랜잭션(transaction)가 삭제됩니다.
다음에 COMMIT PREPARED나 ROLLBACK PREPARED로 트랜잭션(transaction)를식별하기 위한 임의의 식별자입니다. 이 식별자는 캐릭터 라인 리터럴(string litera)로 쓰여져야 합니다. 또, 200바이트 미만이 아니면 안됩니다. 또, 그 시점에서 준비된 트랜잭션(transaction)로서 사용되고 있는 다른 식별자와 같은 것은 사용할 수 없습니다.
이 명령은 트랜잭션(transaction) 블록내에서 사용하지 않으면 안됩니다. 트랜잭션(transaction) 블록을 시작하려면, BEGIN 를 사용해 주세요.
현시점에서는 일시 테이블을 포함한 조작을 실시하는 트랜잭션(transaction)나 커서를 WITH HOLD로 작성하는 트랜잭션(transaction), LISTEN 또는 UNLISTEN를 실행하는 트랜잭션(transaction)를 PREPARE시킬 수 없습니다. 이러한 기능은 준비한 트랜잭션(transaction)로 편리하게 유용하게 사용되려는 현재의 세션에 너무나 강하게 결합되고 있기 때문입니다.
트랜잭션(transaction)로 어떠한 실행시 매개변수가 SET로 설정되어 있는 경우, 그 영향은 PREPARE TRANSACTION의 뒤도 남습니다. 또,COMMIT PREPARED나 ROLLBACK PREPARED의 다음에는 그 영향은 없습니다. 따라서 이 의미에서는 PREPARE TRANSACTION는 ROLLBACK보다 COMMIT와 닮은 움직임이라고 말할 수 있습니다.
그 시점에서 이용할 수 있는 모든 준비된 트랜잭션(transaction)은 pg_prepared_xacts 시스템뷰로 열거됩니다.
성능이라고 하는 점에서는 트랜잭션(transaction)를 장시간 준비 단계 로 유지하는 것은 추천 할 수 없습니다. 구체적으로는 이것은 VACUUM로 개선 단계의 가능성을 방해할 것입니다. 또, 트랜잭션(transaction)가 보관 유지하고 있는 어떠한 락을 계속 보관 유지하는 일도 고려해 주세요. 준비된 트랜잭션(transaction)는 통상 다른 트랜잭션(transaction) 매니저가 다른 데이터베이스로 커밋의 준비를 할 수 있던 것을 확인하자 마자 커밋 또는 롤백(rollback) 된다고 하는 사용 방법을 사용하고 있습니다.
준비된 트랜잭션(transaction)를 본격적으로 사용하는 경우, (사용하지 않는 사람에게 있어서의 쓸데없는 자원 소비를 막기 위해서) 디폴트의 설정에서는 너무 작기 때문에 아마도 max_prepared_transactions의 값을 늘리는 것을 원할 것입니다. 적어도, 모든 세션이 준비된 트랜잭션(transaction)를 대기할 수 있도록 max_connections라고 동치로 하는 것을 권합니다. 그래서 매 세션은 준비된 트랜잭션(transaction) 미결정 상태에 있을 수 있습니다.