| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 12. 동시성 제어 | Fast Forward | Next |
PostgreSQL의 reader는 데이터를 잠그지 않기 때문에, 트랜잭션 격리 레벨과 상관없이 하나의 트랜잭션에 의한 데이터 read는 다른 동시 트랜잭션에 의해 겹쳐 써질 수 있습니다. 바꾸어 말하면, SELECT으로 얻은 행은 그 행이 돌아 왔을 때(때로 현재 쿼리가 시작된 후), 여전히 최신이라는 것을 의미하지 않습니다. 이 트랜잭션이 시작한 다음에도 다른 트랜잭션이 처리한 것으로 보고, 행이 갱신, 혹은 삭제 됐을 가능성이 있습니다. "지금"그 행이 유효했다고 해도 , 현재 실행 중인 트랜잭션이 처리 또는 롤백(rollback)으로 완료하기 전으로(다른 트랜잭션에 의해) 변경되거나 삭제될 가능성이 있습니다.
각각의 트랜잭션은 특정 데이터베이스 내용의 snapshot을 참조하고 있으며, 동시에 실행되고 있는 트랜잭션이 다른 snapshot을 참조하고 있을 가능성도 충분히 있습니다. 따라서, 어느 쪽이든 "지금"이라고 하는 개념은 조금 이상한 정의가 됩니다. 이는 보통, 각 클라이언트 어플리케이션이 서로 격리되고 있는 경우에는 큰 문제가 아니지만, 클라이언트끼리 데이터베이스 밖에서 채널을 통해 통신할 수 있는 경우는 큰 문제가 될 수 있습니다.
현재 유효한 행을 확인하고 동시에 갱신을 피하기 위해서는, SELECT FOR UPDATE문이나 SELECT FOR SHARE문, 적절한 LOCK TABLE문을 사용할 필요가 있습니다 (SELECT FOR UPDATE문이나 SELECT FOR SHARE문은 반환된 행만을 동시 업데이트로부터 잠그고, LOCK TABLE는 테이블 전체를 잠급니다). 이것은 PostgreSQL에 다른 환경의 어플리케이션을 이식할 때 고려되어야만 합니다.
MVCC에 대한 글로벌 유효성 검사가 추가적으로 고려되어집니다. 예를 들면 은행의 어플리케이션으로, 테이블에 있는 모든 대변의 합계가, 다른 테이블에 있는 차변의 합계와 같은 것을 체크할 필요가 있다고 합시다. 그리고 이 양쪽 모두의 테이블은 항상 갱신되고 있습니다. 2개의 연속하는SELECT SUM(...)커멘드의 결과를 비교하면, 2번째 쿼리는, 아마 최초 쿼리에서 카운트되지 않았던 트랜잭션 결과를 포함하기 때문에, Read Committed 모드에서는 신뢰할 수 있는 처리를 실행할 수 없다는 것을 압니다. 1개의 serializable 트랜잭션으로 2개의 합계를 출력하면, 트랜잭션이 개시되기 전에 처리된 결과의 정확한 상황을 얻을 수 있습니다. 그러나 그 결과가 요청된 시점에서도 결과가 적절한지에 관해 실제로는 의심스러울지도 모릅니다. 일관성 체크를 실시하기 전에 serializable 트랜잭션 자신이 변경을 실시했을 경우, 그 체크의 유효성은 한층 더 의심스러워집니다. 트랜잭션 개시 후에 행해지는 모든 변경 뿐 아니라, 무엇인가 다른 것이 포함되었기 때문에입니다. 이러한 경우, 주의 깊은 사람이라면, 현상을 확실히 파악하기 위해서 체크에 필요한 모든 테이블을 잠글 것입니다. SHARE모드(혹은 그 이상)의 락에 의해, 현재 트랜잭션에서의 변경을 제외하고, 락 된 테이블에 처리되지 않은 변경이 존재하지 않는다 라는 것을 보증합니다.
또한, 명시적 락 처리를 사용해, 동시에 변경이 실행되는 것을 막으려고 하는 경우, Read Committed 모드를 사용해야 함을 주의해 주십시요. 혹은, serializable 모드를 사용하는 경우, 쿼리를 실행하기 전에 락을 획득하도록 유의해 주십시요. serializable 트랜잭션에 대해 획득된 락은, 테이블을 변경 하려는 다른 트랜잭션이 현재 실행되지 않았다는 것을 보증합니다. 그러나 트랜잭션이 참조하고 있는 snapshot이, 락의 획득보다 전에 취득된 것이면, 그 snapshot은 현시점서 처리되는 변경보다 전의 테이블의 것일 가능성이 있습니다. serializable 트랜잭션의 snapshot은 실제로 그 최초의 쿼리 혹은 데이터 변경 커멘드(SELECT, INSERT, UPDATE, 또는DELETE)가 개시된 시점에서 취득됩니다. 따라서, snapshot을 취득하기 전에, 명시적으로 락을 획득하는 것은 가능합니다.