[PostgreSQL] Repeatable Read, Serializable에 대해서

저번 글에서 Read Commited에 대해서 알아보았다.

https://vixxcode.tistory.com/236

[PostgreSQL] Read Commited 에 대해서

 

이번 글에서는 남은 트랜잭션 고립 레벨인 Repeatable Read, Serializable에 대해서 알아보는 시간을 가져보도록 해보겠습니다.

 

1. Repeatable Read Isolation Level

반복적 읽기 고립 수준은 트랜잭션 BEGIN 이 전의 커밋 내용들만 볼 수 있습니다.  해당 트랜잭션이 진행 중일 때는 커밋되지 않은 내용이나 커밋된 내용은 볼 수 없습니다. (하지만 같은 트랜잭션 내에서 업데이트 이후에 조회를 했을 때는 업데이트 된 내용을 볼 수 있습니다.)

같은 트랜잭션 내에서는 변화 된 내용을 볼 수 있다

하지만 Read Commited와 달리 다른 트랜잭션에서 값의 변화(생성, 삭제, 변경)가 있더라도 처음 시작한 결과 값 그대로 가져옵니다.

다른 트랜잭션의 결과 값 변화에 대해서 바뀌지 않는다

 

동시에 다른 트랜잭션에 의해 이미 업데이트(삭제 or 잠김) 이 일어난다면?

다른 트랜잭션이 이미 커밋했을 때

검은색 바탕의 사진이 먼저 해당 열에 대한 우선권을 가지게 되었고 커밋을 날렸다.

그에 대한 결과 다른 트랜잭션은 `오류 : 동시 업데이트 때문에 순차적 액세스가 불가능합니다.` 라는 에러 메세지를 받게 된다.

 

다른 트랜잭션이 롤백 했을 때

첫 번째 트랜잭션이 id가 1번인 row에 대한 락을 가지고 있지만 롤백함으로써 다른 트랜잭션에 대한 수행이 제대로 이루어진 것을 보실 수 있습니다.

 

 

Serializable Isolation Level

직렬화 고립 수준은 트랜잭션 고립 수준에서 가장 엄격한 수준입니다. 해당 트랜잭션 고립 수준으로 진행이 되면 트랜잭션들은 동시에 일어나지 않고 순차적으로 일어나게 됩니다. 

 

현재 테이블 상태

 id | balance | name  
----+---------+-------
  1 |    2000 | tom
  2 |    8000 | mike
  3 |    9000 | sena
  4 |    3000 | john
  5 |    2000 | alice
  6 |    1000 | ani
  7 |    4000 | mike
  8 |    5000 | mike
  9 |    6000 | mike
 10 |    7000 | sena
 11 |    2500 | sena
 12 |   12500 | sena
 13 |    2000 | sena
 14 |    2000 | sena
(14 rows)

 

 

• 첫 번째 트랜잭션은 'sena'이름으로 된 잔액의 총합을 구하고 'mike'라는 이름을 가진 row를 생성하고 commit 하는 상황
• 두 번째 트랜잭션은 'mike'이름으로 된 잔액의 총합을 구하고, 'sena'라는 이름을 가진 row를 생성하고 commit하는 상황

이 때 두개의 트랜잭션 중 하나는 무조건 실패를 하게 된다.( 현재 캡처 사진에서는 두 번째 트랜잭션이 실패한 것을 볼 수가 있다.)

 

그 이유는 하나의 트랜잭션을 기준으로 전과 후의 값이 달라지기 때문에 직렬화 이상으로 에러 메세지를 내보내게 된다.

 

 

Phantom Read는 PostgreSQL에서 보일까? 안 보일까?

결론부터 말하자면 안 보인다. 자세한 글은 바로 아래 링크를 눌러서 보시길 바란다.

https://postgresql.kr/blog/pg_phantom_read.html

트랜잭션 격리 이야기에서 팬텀 읽기 현상

 

필자 또한 유령읽기에 대해서 간단하게 진행해보았다.

 

• 첫 번째 트랜잭션에서 해당 테이블에 대해서 새로운 row를 추가했다.

• 두 번째 트랜잭션에서는 조회를 반복적으로 진행했다.

그 결과 유령 읽기는 postgreSQL에서 Repeatable Read 단계에서는 볼 수없는 것으로 확인된다.