반복 가능한 읽기의 불일치

http://www.postgresql.org/docs/9.2/static/transaction-iso.html

반복 가능한 읽기 모드는 각 트랜잭션이 데이터베이스를 완전히 안정적으로 볼 수 있도록 보장합니다. 그러나이 관점이 반드시 동일한 레벨의 동시 트랜잭션의 일부 (한 번에 하나씩) 실행과 항상 일치하는 것은 아닙니다. 예를 들어,이 레벨의 읽기 전용 트랜잭션조차도 배치가 완료되었음을 표시하기 위해 제어 레코드가 업데이트되었지만 제어 레코드의 이전 개정을 읽었으므로 배치의 논리적 부분 인 세부 레코드 중 하나를 볼 수 없습니다. . 이 격리 수준에서 실행되는 트랜잭션으로 비즈니스 규칙을 적용하려는 시도는 충돌하는 트랜잭션을 차단하기 위해 명시 적 잠금을 신중하게 사용하지 않으면 제대로 작동하지 않을 수 있습니다.

반복 읽기 모드에서는 불가능한 팬텀 읽기가 아닙니까?

문서에 따르면 반복 읽기 트랜잭션의 쿼리는 트랜잭션이 시작될 때 스냅 샷을보고 쿼리에서 일치하지 않는 데이터를 읽을 수있는 방법은 무엇입니까?

여기 그 섹션을 읽었습니다. 혼란 스럽습니다.

두 개의 테이블이 있다고 가정하십시오.

CREATE TABLE batch (
   id serial not null unique,
   control_code text primary key,
   date_posted date not null default now()
);

CREATE TABLE details (
   batch_id int not null references batch(id),
   description text,
   primary key(batch_id, description)
);

이제 다른 트랜잭션에 배치 및 세부 사항 레코드를 삽입한다고 가정하십시오. 세션 1은 배치를 삽입하고 세부 사항을 삽입하기 시작하지만 완료되기 전에 세션 2가 시작됩니다. 세션 2는 배치 표제 정보를 볼 수 있지만 사용자가 레코드를 찾을 수 없음을 알리기 위해 세부 사항에 대한 커미트를 기다리지 않습니다. 이제 배치 및 세부 사항이 완전히 동일한 트랜잭션에있는 경우 이는 문제가되지 않습니다.

이것은 행을 찾을 수 없음을 사용자에게 알리기 전에 이전 삽입이 완료되고 커미트 또는 롤백 될 때까지 기다릴 것으로 예상되는 직렬화 가능과 다릅니다.

이 문서 복 읽기 트랜잭션 격리 수준에서 거래의 특정 조합에서 발생할 수있는 몇 가지 문제를 보여 PostgreSQL의 위키에서이, 그리고 그들은 PostgreSQL을 버전 9.1로 SERIALIZABLE 트랜잭션 격리 수준의 시작 부분에 방지하는 방법.

또한 REPEATABLE READ 레벨 READ-ONLY 트랜잭션이 일치하지 않는 데이터를 읽는 방법에 대한 예도 포함합니다 .

원칙적으로 "반복 가능한 읽기"격리 수준에서 팬텀 읽기 (반복 불가능한 읽기와 혼동하지 마십시오)가 가능합니다. 그러나 "반복 가능한 읽기"를 선택할 때 Postgresql의 사실상의 동작은 표준보다 강력하므로 (거의 "직렬화 가능"격리) 사실상 팬텀 읽기는 없습니다. 문서 :

Read Uncommitted 레벨을 선택하면 실제로 Read Committed를 받게 되며 PostgreSQL 구현의 Repeatable Read에서 팬텀 읽기가 불가능 하므로 실제 격리 수준은 선택한 것보다 엄격 할 수 있습니다.

이제이 경고는 "동일한 수준의 동시 트랜잭션을 한 번에 하나씩 연속적으로 실행하는 것과 반드시 ​​일치하지는 않습니까?" 나는 그것이 확실하지 않다는 것을 의미한다는 것을 의미한다. 그것은 "외부에서"(트랜잭션 시작시 고정) 스냅 샷이 결국 다른 트랜잭션의 행을 포함 할 수 있지만 동일한 트랜잭션의 다른 행을 포함하지 못한다는 것을 의미한다.