llm-wiki/raw/official-docs/postgres-transaction-isolation-official.md

title, source_type, url, archive_url, vendor, related_branches, related_projects, tags, created

title	source_type	url	archive_url	vendor	related_branches	related_projects	tags	created
official-doc / PostgreSQL Transaction Isolation — MVCC 격리 수준 보장 공식 레퍼런스	official-doc	https://www.postgresql.org/docs/current/transaction-iso.html		PostgreSQL Global Development Group	feature-transaction-concurrency-contract	ca-skeleton	official-doc ca-skeleton persistence postgresql transaction-isolation mvcc	2026-06-09

official-doc / PostgreSQL Transaction Isolation — MVCC 격리 수준 보장 공식 레퍼런스

Layer: raw/official-docs/ — PostgreSQL 공식 문서의 트랜잭션 격리 수준(READ COMMITTED / REPEATABLE READ / SERIALIZABLE) 보장 범위 원문 발췌. 검증된 요약은 /ingest 후 wiki/concepts/에 별도 작성. 원본은 raw에 영구 보관.

Parent / 활용 branch

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-transaction-concurrency-contract	ca-tmpl TransactionPort 가 ISOLATION_READ_COMMITTED 를 기본값으로 채택하고 REPEATABLE_READ/SERIALIZABLE 을 명시 opt-in 으로 예약한 근거 (D3). PostgreSQL MVCC snapshot semantics, dirty/non-repeatable/phantom read 방지 범위, 직렬화 실패 에러를 vendor SSOT 로 확보.

출처 / Source

• 원본 URL: https://www.postgresql.org/docs/current/transaction-iso.html
• 아카이브 URL: (미수집)
• 저자 / 조직: PostgreSQL Global Development Group
• 발행일: PostgreSQL 18 Documentation (current)
• 마지막 확인일: 2026-06-09

왜 저장했는지 / Why archived

feature-transaction-concurrency-contract D3 결정("isolation level default = READ_COMMITTED, PostgreSQL/MySQL 양쪽 동일 의미") 이 UNSUPPORTED_DECISION 으로 라벨된 상태였다. 이 페이지는 PostgreSQL vendor SSOT 로서 READ COMMITTED / REPEATABLE READ / SERIALIZABLE 의 정확한 보장 범위(MVCC snapshot 단위, 허용되지 않는 현상, 직렬화 실패 에러 메시지)를 verbatim 으로 제공한다.

핵심 인용 / Key quotes (verbatim, 5문장)

[§13.2.1] "Read Committed is the default isolation level in PostgreSQL. When a transaction uses this isolation level, a SELECT query (without a FOR UPDATE/SHARE clause) sees only data committed before the query began; it never sees either uncommitted data or changes committed by concurrent transactions during the query's execution. In effect, a SELECT query sees a snapshot of the database as of the instant the query begins to run." — 위치: §13.2.1 Read Committed Isolation Level, line 29 in fetched text

[§13.2.1] "a SELECT query sees a snapshot of the database as of the instant the query begins to run." — 위치: §13.2.1, line 29 (statement-level snapshot 핵심 문장)

[§13.2.2] "a query in a repeatable read transaction sees a snapshot as of the start of the first non-transaction-control statement in the transaction, not as of the start of the current statement within the transaction. Thus, successive SELECT commands within a single transaction see the same data, i.e., they do not see changes made by other transactions that committed after their own transaction started." — 위치: §13.2.2 Repeatable Read Isolation Level, line 41 in fetched text

[§13.2.2] "ERROR: could not serialize access due to concurrent update" — 위치: §13.2.2, line 47 (REPEATABLE READ 충돌 시 반환되는 실제 에러 메시지)

[§13.2.3] "The Serializable isolation level provides the strictest transaction isolation. This level emulates serial transaction execution for all committed transactions; as if transactions had been executed one after another, serially, rather than concurrently. However, like the Repeatable Read level, applications using this level must be prepared to retry transactions due to serialization failures. In fact, this isolation level works exactly the same as Repeatable Read except that it also monitors for conditions which could make execution of a concurrent set of serializable transactions behave in a manner inconsistent with all possible serial (one at a time) executions of those transactions. This monitoring does not introduce any blocking beyond that present in repeatable read, but there is some overhead to the monitoring, and detection of the conditions which could cause a serialization anomaly will trigger a serialization failure." — 위치: §13.2.3 Serializable Isolation Level, line 59 in fetched text

[§13.2 intro] "In PostgreSQL, you can request any of the four standard transaction isolation levels, but internally only three distinct isolation levels are implemented, i.e., PostgreSQL's Read Uncommitted mode behaves like Read Committed. This is because it is the only sensible way to map the standard isolation levels to PostgreSQL's multiversion concurrency control architecture." — 위치: §13.2 Transaction Isolation, line 21 in fetched text

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
PG-ISO-C1	PostgreSQL 의 기본 격리 수준은 READ COMMITTED 이다	[§13.2.1] "Read Committed is the default isolation level in PostgreSQL."	official-vendor-doc	PostgreSQL (모든 현행 버전)	MySQL InnoDB 의 기본 격리 수준 (별도 확인 필요). Spring @Transactional 의 기본 isolation 설정값 (Spring default = DEFAULT, 즉 vendor 위임)
PG-ISO-C2	READ COMMITTED 에서 SELECT 는 문장 시작 시점의 스냅샷을 사용한다 (statement-level snapshot)	[§13.2.1] "a SELECT query sees a snapshot of the database as of the instant the query begins to run."	official-vendor-doc	PostgreSQL READ COMMITTED isolation level	동일 트랜잭션 내 두 번째 SELECT 가 같은 데이터를 본다는 보장 — READ COMMITTED 에서는 각 문장마다 새 스냅샷 (non-repeatable read 허용)
PG-ISO-C3	REPEATABLE READ 에서 SELECT 는 트랜잭션 시작 시점의 스냅샷을 사용한다 (transaction-level snapshot). 동일 트랜잭션 내 연속 SELECT 는 같은 데이터를 본다	[§13.2.2] "a query in a repeatable read transaction sees a snapshot as of the start of the first non-transaction-control statement in the transaction, not as of the start of the current statement within the transaction. Thus, successive SELECT commands within a single transaction see the same data, i.e., they do not see changes made by other transactions that committed after their own transaction started."	official-vendor-doc	PostgreSQL REPEATABLE READ isolation level	MySQL InnoDB REPEATABLE READ 동작 (PostgreSQL 과 다를 수 있음 — consistent read 의 차이). 분산 트랜잭션 환경에서의 동일 보장
PG-ISO-C4	REPEATABLE READ 트랜잭션이 다른 트랜잭션이 변경한 행을 수정하려 하면 ERROR: could not serialize access due to concurrent update 에러로 롤백된다	[§13.2.2] "ERROR: could not serialize access due to concurrent update"	official-vendor-doc	PostgreSQL REPEATABLE READ write 충돌 시나리오	이 에러가 Spring OptimisticLockingFailureException 으로 자동 변환된다는 보장 (Spring Data 예외 변환 계층 별도 확인 필요)
PG-ISO-C5	SERIALIZABLE 은 동시 트랜잭션 집합이 직렬 실행과 동일한 결과를 생성하지 않을 조건을 감지 시 serialization failure 를 발생시킨다. 직렬화 이상 발생 시 반환 에러: ERROR: could not serialize access due to read/write dependencies among transactions	[§13.2.3] "The Serializable isolation level provides the strictest transaction isolation. [...] detection of the conditions which could cause a serialization anomaly will trigger a serialization failure."	official-vendor-doc	PostgreSQL SERIALIZABLE isolation level	SERIALIZABLE 을 사용하는 모든 use case 가 재시도 없이 성공한다는 보장. 모니터링 오버헤드 규모 (측정값 미제공)
PG-ISO-C6	PostgreSQL 은 내부적으로 세 가지 격리 수준만 구현한다. READ UNCOMMITTED 는 READ COMMITTED 와 동일하게 동작한다	[§13.2 intro] "internally only three distinct isolation levels are implemented, i.e., PostgreSQL's Read Uncommitted mode behaves like Read Committed. This is because it is the only sensible way to map the standard isolation levels to PostgreSQL's multiversion concurrency control architecture."	official-vendor-doc	PostgreSQL MVCC 아키텍처	MySQL / Oracle 등 다른 RDBMS 에서 동일하게 READ UNCOMMITTED 가 READ COMMITTED 로 동작한다는 보장

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:

  • PG-ISO-C1: PostgreSQL 의 기본 격리 수준이 READ COMMITTED 임 (D3 UNSUPPORTED_DECISION 해소 근거)
  • PG-ISO-C2: READ COMMITTED 에서 SELECT 는 statement-level snapshot (각 문장마다 새 스냅샷)
  • PG-ISO-C3: REPEATABLE READ 에서 SELECT 는 transaction-level snapshot (트랜잭션 시작 시점 고정)
  • PG-ISO-C4: REPEATABLE READ write 충돌 시 구체적인 에러 메시지 + 롤백 동작
  • PG-ISO-C5: SERIALIZABLE 의 직렬화 이상 감지 + serialization failure 에러 메시지
  • PG-ISO-C6: PostgreSQL 내부적으로 3가지 격리 수준만 존재 (READ UNCOMMITTED = READ COMMITTED)

• 이 자료가 증명하지 않는 것:

  • MySQL InnoDB 의 READ COMMITTED 시맨틱이 PostgreSQL 과 동일하다는 것 (MySQL 별도 raw 수집 필요)
  • Spring @Transactional(isolation = Isolation.READ_COMMITTED) 설정이 PostgreSQL 에서 이 시맨틱을 정확히 전달한다는 것 (Spring DataSource TransactionManager 동작 별도 확인 필요)
  • REPEATABLE READ 충돌 에러(PG-ISO-C4)가 Spring Data 예외 변환 계층에서 OptimisticLockingFailureException 으로 변환된다는 것
  • 분산 트랜잭션(XA, Saga) 환경에서의 격리 보장

• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:

  • MySQL InnoDB 격리 수준 공식 문서 별도 raw 수집 (https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html)
  • Spring TransactionPort 어댑터가 HikariCP + PostgreSQL 드라이버를 통해 격리 수준을 정확히 전달하는지 integration test 검증 (feature-transaction-concurrency-contract Claims To Verify 항목)

메모 / Notes

• D3 UNSUPPORTED_DECISION 해소: PG-ISO-C1 이 "READ COMMITTED 는 PostgreSQL 기본값" 을 verbatim 으로 증명. 단 MySQL InnoDB 쪽은 별도 raw 수집 전까지 여전히 UNSUPPORTED_DECISION 상태 유지.
• Table 13.1 (격리 수준 × 허용 현상 행렬): PostgreSQL 의 REPEATABLE READ 는 SQL 표준보다 강한 보장 제공 — phantom read 도 방지 (SQL 표준은 허용). 이 점이 MySQL InnoDB REPEATABLE READ (gap lock 기반 phantom read 방지) 와 구현 메커니즘은 다르지만 보장 결과는 유사함을 시사 — 단 verbatim 비교는 MySQL raw 수집 후 별도 검증 필요.
• SERIALIZABLE 구현: PostgreSQL 9.1+ 부터 Serializable Snapshot Isolation(SSI) 사용. 이전 버전은 REPEATABLE READ 와 동일 동작이었음 (문서 Note 참조).

Related / 관련

• MySQL InnoDB 격리 수준 (미수집): https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html
• Spring Framework TX isolation 설정: raw/official-docs/spring-tx-management-reference
• @Transactional 공식 문서: raw/official-docs/at-transactional-spring-official
• 이 자료를 인용한 wiki 요약: [[wiki/concepts/transaction-isolation]] (생성 시)