Postgresql 잠 금 메커니즘 상세 설명(표 잠 금 및 행 잠 금)

시계 자물쇠
LOCK [ TABLE ] [ ONLY ] name [ * ] [, ...] [ IN lockmode MODE ] [ NOWAIT ]
lockmode 는 다음 과 같은 몇 가 지 를 포함한다.
ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE| SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE
LOCK TABLE 명령 은 시계 자 물 쇠 를 가 져 오 는 데 사 용 됩 니 다.가 져 오 는 과정 은 기다 리 는 자물쇠 가 다른 사무 에 의 해 방출 될 때 까지 막 힙 니 다.NOWAIT 키 워드 를 사용 하면 잠 금 을 가 져 오지 못 하면 기다 리 지 않 고 바로 돌아 가 현재 명령 을 실행 하 는 것 을 포기 하고 오류(error)를 던 집 니 다.자 물 쇠 를 가 져 오 면 업무 가 끝 날 때 까지 자 물 쇠 를 가지 고 있 습 니 다.(자 물 쇠 를 자발적으로 풀 라 는 명령 이 없 으 면 자 물 쇠 는 항상 업무 가 끝 날 때 방출 된다.
자동 으로 자 물 쇠 를 가 져 오 는 모드 를 사용 할 때 PostgreSQL 은 가능 한 한 최소 모드 를 사용 합 니 다.LOCK TABLE 명령 은 자물쇠 의 제한 크기 를 스스로 정의 할 수 있 습 니 다.예 를 들 어 한 프로그램 이 업 무 를 사용 하여 읽 기 제출(Read Committed isolation level)모드 에서 데이터 베 이 스 를 트 랜 잭 션 기간 동안 안정 적 으로 유지 해 야 하기 때문에 SHARE 잠 금 모드 를 사용 하여 읽 기 전에 표를 잠 글 수 있 습 니 다.이것 은 동시 다발 적 인 데이터 변 화 를 방지 하고 후속 적 인 업무 가 이 표 의 읽 기 에 제출 되 지 않 은 데 이 터 를 읽 지 않도록 보장 할 수 있 습 니 다.SHARE 자물쇠 와 기록 업무 가 가지 고 있 는 ROW EXCLUSIVE 자물쇠 가 충돌 하기 때문에 SHARE 자 물 쇠 를 사용 하여 표 에 자 물 쇠 를 추가 하려 는 일 은이 시 계 를 가지 고 있 는 모든 ROW EXCLUSIVE 잠 금 사무 commt 나 roll back 을 기다 릴 것 입 니 다.따라서 표 의 SHARE 자 물 쇠 를 가 져 오 면 제출 하지 않 은 데이터 가 없 을 것 이 며,현재 트 랜 잭 션 이 SHARE 자 물 쇠 를 풀 때 까지 다른 트 랜 잭 션 이 변경 되 지 않 을 것 입 니 다.
REPEATABLE READ(중복 읽 기)모드 와 SERIALIZABLE(직렬 화)모드 에서 같은 효 과 를 얻 기 위해 서 는 모든 조회 와 문장 수정 전에 LOCK TABLE 을 추가 해 야 합 니 다.첫 번 째 SELECT 문 구 를 실행 하거나 데이터 문 구 를 수정 하기 전에 반복 읽 기와 직렬 화 모드 에서 한 업무 의 데이터 보 기 는 스냅 샷 으로 저 장 됩 니 다.이러한 상황 에서 트 랜 잭 션 에 명 시 된 잠 금 역시 동시 다발 적 인 수정 을 피 할 수 있 지만 이 트 랜 잭 션 이 최신 제출 한 데 이 터 를 읽 을 수 있 을 것 이 라 고 보장 할 수 는 없다.
표 의 데 이 터 를 수정 하려 면 SHARE ROW EXCLUSIVE(공유 줄 배타)자 물 쇠 를 사용 해 야 합 니 다.공유 줄 배타 자 물 쇠 는 같은 시간 에 현재 업무 만 실행 할 수 있 도록 보장 할 수 있 습 니 다.이 자 물 쇠 를 추가 하지 않 으 면 잠 금 이 사라 질 수 있 습 니 다.두 개의 사무 가 동시에 SHARE 자 물 쇠 를 가 져 오 려 고 하고 그 다음 에 ROW EXCLUSIVE 자 물 쇠 를 동시에 가 져 와 서 데이터 업 데 이 트 를 하려 고 합 니 다.(주의:같은 사무 에서 가 져 온 두 가지 다른 자 물 쇠 는 충돌 하지 않 기 때문에 같은 사무 에 대해 서 는 SHARE 자 물 쇠 를 가 져 온 후에 ROW EXCLUSIVE 를 다시 가 져 올 수 있 습 니 다.물론 다른 사무 없 이 SHARE 자 물 쇠 를 가 져 온 경우).잠 금 을 피하 기 위해 서 는 모든 업무 가 같은 대상 의 자 물 쇠 를 가 져 오 는 순서 가 일치 하도록 해 야 합 니 다.또한 같은 대상 에서 여러 개의 자 물 쇠 를 가 져 오 려 면 항상 제한 이 가장 큰 자 물 쇠 를 가 져 와 야 합 니 다.
액세스 공유(액세스 공유 잠 금)
ACCESS EXCLUSIVE 잠 금 과 만 충돌 합 니 다.
SELECT 명령 은 현재 조회 한 표 에서 ACCESS SHARE 자 물 쇠 를 가 져 옵 니 다.전반적 으로 읽 기 전용 작업 은 이 자 물 쇠 를 가 져 옵 니 다.
ROW SHARE(줄 공유 자물쇠)
EXCLUSIVE 자물쇠 와 ACCESS EXCLUSIVE 자물쇠 가 충돌 합 니 다.
SELECT FOR UPDATE 나 SELECT FOR SHARE 명령 은 대상 표 에서 이 자 물 쇠 를 가 져 오고 인용 되 지만 FOR UPDATE 가 없 는 표 에 ACCESS SHARED 자 물 쇠 를 추가 합 니 다.
ROW EXCLUSIVE(줄 타 자물쇠)
SHARE,SHARE ROW EXCLUSIVE 와 ACCESS EXCLUSIVE 자물쇠 가 충돌 합 니 다.
UPDATE,DELETE,INSERT 는 타 겟 시트 에서 이 자 물 쇠 를 가 져 옵 니 다.전체적으로 데이터베이스 데 이 터 를 수정 하 는 명령 은 이 자 물 쇠 를 가 져 옵 니 다.
SHARE UPDATE EXCLUSIVE(공유 업데이트 배타 적 잠 금)
SHARE UPDATE EXCLUSIVE,SHARE ROW EXCLUSIVE,EXCLUSIVE 와 ACCESS EXCLUSIVE 가 충돌 합 니 다.이 잠 금 은 시계 가 병발 하 는(schema)변경 과 VACUUM(방출 공간)명령 을 방지 할 수 있 습 니 다.
VACUUM,ANALYZE,CREATE INDEX CONCURRENTLY 와 ALTER TABLE VALIDATE 및 기타 ALTER TABLE 류 의 명령 은 이 자 물 쇠 를 가 져 옵 니 다.
공유(공유 자물쇠)
ROW EXCLUSIVE,SHARE UPDATE EXCLUSIVE,SHARE ROW EXCLUSIVE,EXCLUSIVE 와 ACCESS EXCLUSIVE 자물쇠 가 충돌 합 니 다.이 잠 금 은 동시 다발 적 인 데이터 변 화 를 방지 하기 위해 시 계 를 보호 한다.
CREATE INDEX 명령 으로 얻 을 수 있 습 니 다.
SHARE ROW EXCLUSIVE(줄 공유 배타 적 잠 금)
ROW EXCLUSIVE,SHARE UPDATE EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE 및 ACCESS EXCLUSIVE 자물쇠 와 충돌 합 니 다.이 자 물 쇠 는 시계 가 병발 하 는 데이터 변 화 를 방지 하 는 동시에 자기 배열 이기 때문에 같은 시간 에 같은 session 만 이 자 물 쇠 를 가 질 수 있 습 니 다.
이 잠 금 은 PGSQL 의 어떤 명령 에 도 자동 으로 가 져 오지 않 습 니 다.
EXCLUSIVE(자물쇠 배열)
ROW SHARE,ROW EXCLUSIVE,SHARE UPDATE EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE 와 ACCESS EXCLUSIVE 자물쇠 가 충돌 합 니 다.이 자 물 쇠 는 동시 다발 적 인 ACCESS SHARE 자물쇠 만 허용 되 며,읽 기 동작 만 이 배타 적 자 물 쇠 를 가지 고 있 을 때 동시 다발 적 으로 작 동 할 수 있다.
액세스 EXCLUSIVE(액세스 배타 적 잠 금)
모든 자물쇠 와 충돌 합 니 다.이 자 물 쇠 는 자 물 쇠 를 가 진 업무 만 현재 표 에 접근 할 수 있 도록 보장 합 니 다.
DROP TABLE,TRUncate,REINDEX,CLUSTER,VACUUM FULL,REFRESH MATERIALIZED VIEW 명령 에 의 해 자동 으로 가 져 옵 니 다.여러 가지 형식의 ALTER TABLE 명령 으로 이 자 물 쇠 를 가 져 올 수 있 습 니 다.LOCK TABLE 명령 의 기본 잠 금 단계 이기 도 합 니 다.
ACCESS EXCLUSIVE 자물쇠 만 SELECT 문 구 를 방지 할 수 있 습 니 다.
주의 하 다.
자 물 쇠 를 가 져 옵 니 다.업무 가 끝 날 때 만 풀 립 니 다.그러나 하나의 자물쇠 가 savepoint(저장 점)이후 에 가 져 오 면 이 저장 점 이 스크롤 백 할 때 이 자 물 쇠 는 바로 풀 립 니 다.

행 자물쇠
시계 자물쇠 뿐만 아니 라 PgSQL 은 줄 자물쇠 도 제공 합 니 다.하나의 사 무 는 서로 충돌 하 는 두 줄 의 자 물 쇠 를 가 져 올 수 있 습 니 다.하위 사 무 를 포함 하지만 두 사 무 는 같은 줄 에서 서로 충돌 하 는 두 가지 자 물 쇠 를 동시에 가 져 올 수 없습니다.
FOR UPDATE
FOR UPDATE 잠 금 으로 SELECT 문 구 는 줄 잠 금 을 가 져 와 데 이 터 를 업데이트 할 수 있 습 니 다.이 줄 은 다른 업무 에 의 해 자 물 쇠 를 가 져 오 거나 삭제 작업 을 변경 하 는 것 을 방지 할 수 있 습 니 다.즉,다른 업무 의 작업 이 현재 업무 가 끝 날 때 까지 막 힐 수 있 습 니 다.마찬가지 로 SELECT FOR UPDATE 명령 은 이전 업무 가 끝 날 때 까지 기다 릴 것 이다.REPEATABLE 모드 나 SERIALIZABLE 모드 에서 잠 길 줄 이 시작 되 기 전에 삭제 되면 error 를 되 돌려 줍 니 다.
FOR UPDATE 잠 금 역시 DELETE 명령 에 의 해 가 져 올 수 있 으 며,UPDATE 명령 은 정 해진 줄 에서 데 이 터 를 수정 할 때 도 이 잠 금 을 가 져 올 수 있 습 니 다.현재 확 정 된 유일한 색인 을 사용 할 때 UPDATE 명령 을 사용 하면 이 잠 금(일부 색인 과 연합 색인 은 일시 적 으로 지원 되 지 않 음)을 얻 을 수 있 지만 앞으로 이 디자인 이 바 뀔 수 있 습 니 다.
FOR NO KEY UPDATE
FOR UPDATE 명령 과 유사 하지만 자 물 쇠 를 가 져 오 는 것 에 대한 요구 가 더 느슨 하고 같은 줄 에서 SELECT FOR KEY SHARE 명령 을 막 지 않 습 니 다.마찬가지 로 UPDATE 명령 때 FOR UPDATE 자 물 쇠 를 가 져 오지 않 으 면 이 자 물 쇠 를 가 져 옵 니 다.
FOR SHARE
FOR NO KEY UPDATE 명령 과 유사 합 니 다.다른 점 은 이 자 물 쇠 는 이전 자물쇠 가 아 닌 공유 자물쇠 이기 때문에 이 자 물 쇠 는 UPDATE,DELETE,SELECT FOR UPDATE 또는 SELECT FOR NO KEY UPDATE 를 막 지만 SELECT FOR SHARE 또는 SELECT FOR KEY SHARE 를 막 지 않 습 니 다.
FOR KEY SHARE
FOR SHARE 와 비슷 한 표현 이지 만 잠 금 추가 에 대한 요구 가 더 느슨 해 지면 SELECT FOR UPDATE 가 막 히 지만 SELECT FOR NO KEY UPDATE 는 막 히 지 않 습 니 다.KEY SHARE 모드 의 잠 금 은 다른 업무 의 DELETE 나 KEY 값 을 바 꾸 는 UPDATE 문 구 를 막 지만 다른 UPDATE 나 SELECT FOR NO KEY UPDATE,SELECT FOR SHARE,SELECT FOR KEY SHARE 는 막 히 지 않 습 니 다.

추가:Postgresql 잠 금 처리
오늘 이상 한 현상 이 발생 했 습 니 다.select 와 delete 표 는 정상적으로 실행 되 지만 truncate 와 drop 표 는 계속 실행 되 고 오류 가 발생 하지 않 습 니 다.
몇 가지 자 료 를 조사해 서 야 문제 의 원인 을 발견 하 였 는데,총 결 은 다음 과 같다.
"drop table"과"truncate table"은"ACCESS EXCLUSIVE"를 잠 그 는 것 을 신청 해 야 합 니 다.이 명령 이 걸 렸 을 때 이 표 에 작업 이 진행 되 고 있 음 을 설명 합 니 다.예 를 들 어 조회 등 이 있 으 면 이 조회 작업 이 완료 되 기 를 기 다 려 야 합 니 다."drop table"이나"truncate table"또는 필드 를 추가 한 SQL 만 이 표 의"ACCESS EXCLUSIVE"자 물 쇠 를 가 져 올 수 있 습 니 다.조작 해야만 진행 할 수 있다.
1.잠 금 프로 세 스 의 ID 를 검색 합 니 다.
SELECT * FROM pg_stat_activity WHERE datname='잠 긴 데이터베이스 ID';
검색 한 필드 에서[wating]필드,데이터 가 t 인 것 이 바로 잠 겨 있 는 프로 세 스 입 니 다.대응 하 는[procpid]열의 값 을 찾 습 니 다.
2.프로 세 스 를 죽인다.
SELECT pg_cancel_backend('그 데이터 의 procpid 값 잠 금');
결과:실행 이 끝 난 후에 이 표를 다시 업데이트 하면 sql 이 순조롭게 실 행 됩 니 다.
하면,만약,만약...stat_activity 기록 이 없 으 면 pg 조회locks 이 대상 의 자물쇠 가 있 는 지 여부

select oid,relname from pg_class where relname='table name';
select locktype,pid,relation,mode,granted,* from pg_locks where relation= '       oid';
 
select pg_cancel_backend('  ID');

그리고 pgterminate_backend()함수 도 프로 세 스 를 죽 일 수 있 습 니 다.
이상 은 개인 적 인 경험 이 므 로 여러분 에 게 참고 가 되 기 를 바 랍 니 다.여러분 들 도 저 희 를 많이 응원 해 주시 기 바 랍 니 다.만약 잘못 이 있 거나 완전히 고려 하지 않 은 부분 이 있다 면 아낌없이 가르침 을 주시 기 바 랍 니 다.