| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 12. 동시성 제어 | Fast Forward | Next |
PostgreSQL는 테이블 내, 데이터에 대한 동시 접근을 제어하기 위해서 여러가지 종류의 락 모드를 갖추고 있습니다. MVCC에서 필요한 동작을 얻을 수 없는 경우, 이러한 모드를 어플리케이션 제어 락에 사용할 수 있습니다. 또한, 대부분의 PostgreSQL커멘드는 참조된 테이블이 커멘드의 실행 중에 다른 방법으로 삭제나 변경되지 않았다는 것을 확실히 하기 위해서, 적절한 모드의 락을 자동으로 얻습니다. (예를 들어, ALTER TABLE커멘드는 같은 테이블의 다른 연산과 동시에 실행하는 것은 위험합니다. 이로 인해, 테이블의 배타 락을 강제로 획득합니다.).
현재 데이터베이스 서버에서 중요한 락 리스트를 확인하려면, pg_locks 시스템 뷰를 사용해 주십시요. 락 관리 상태를 모니터링하는 것에 대한 자세한 사항은 Chapter 25을 참조해 주십시요.
이하의 리스트는 PostgreSQL에서 자동으로 사용되는 이용 가능한 락 모드와 그 문맥을 나타냅니다. 또한, LOCK 커멘드를 사용해, 이러한 락을 명시적으로 획득할 수도 있습니다. 이러한 락 모드는, 비록 이름에 "row(행)"라는 말이 붙어 있어도, 모두 테이블 레벨의 락이라는 것을 주의해 주십시요. 락 모드의 이름은 역사적인 것입니다. 이러한 이름은, 각각의 락 모드의 대표적인 사용법을 일부 나타내고 있습니다. 그러나 의미적으로는 모두 같습니다. 락 모드 간의 유일한 실질적인 차이는, 어느 모드끼리 충돌하는가 하는 락 모드의 마찰입니다. 두 개의 트랜잭션은 동시에 같은 테이블 상에서 충돌하는 락을 가질 수 없습니다. (그러나 트랜잭션은 자기 자신과는 결코 충돌하지 않습니다. 예를 들어, ACCESS EXCLUSIVE락을 획득해, 그 후 같은 테이블에ACCESS SHARE락을 획득할 수 있을 가능성이 있습니다). 충돌하지 않는 락 모드는 동시에 많은 트랜잭션을 가질 수 있습니다. 특히, 락 모드에는 자기 충돌하는 것(예를 들면, ACCESS EXCLUSIVE 락은 동시에 다수의 트랜잭션에서 가질 수 없음)과 자기 충돌하지 않는 것(예를 들면, ACCESS SHARE 락은 복수의 트랜잭션에서 가질 수 있음)이 있는 것을 주의해 주십시요.
테이블 레벨 락 모드
오직 ACCESS EXCLUSIVE락 모드와 충돌합니다.
SELECT커멘드는 참조된 테이블의 이 모드에 대한 락을 얻습니다. 보통, 테이블을 읽는 것만으로 변경을 실행하지 않는 쿼리의 경우, 모두 이 락 모드를 갖습니다.
EXCLUSIVE 및 ACCESS EXCLUSIVE락 모드와 충돌합니다.
SELECT FOR UPDATE 및 SELECT FOR SHARE커멘드는 (참조되지만 FOR UPDATE/FOR SHARE을 선택하지 않은 다른 테이블에 대해 ACCESS SHARE락에 추가됨) 목표 테이블에서 이 모드의 락을 얻습니다.
SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, 및 ACCESS EXCLUSIVE락 모드와 충돌합니다.
UPDATE, DELETE, 및 INSERT커멘드는 (참조되는 다른 모든 테이블에 대한 ACCESS SHARE락에 가세해) 목표 테이블에서 이 모드의 락을 획득합니다. 보통, 이 락 모드는 테이블의 데이터를 변경하는 쿼리에 의해 획득됩니다.
SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, 및 ACCESS EXCLUSIVE락 모드와 충돌합니다. 이 모드에 의해 동시 실행되는 스키마의 변경 및 VACUUM커멘드의 실행으로부터 테이블을 보호합니다.
(FULL 없이)VACUUM커멘드, ANALYZE커멘드, 및 CREATE INDEX CONCURRENTLY에 의해 획득됩니다.
ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE, 및 ACCESS EXCLUSIVE락 모드와 충돌합니다. 이 모드에 의해, 동시에 진행되는 데이터 변경으로부터 테이블을 보호합니다.
(CONCURRENTLY없이)CREATE INDEX에 의해 획득됩니다.
ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, 및 ACCESS EXCLUSIVE락 모드와 충돌합니다.
이 락 모드를 자동으로 획득하는PostgreSQL커멘드는 없습니다.
ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, 및 ACCESS EXCLUSIVE락 모드와 충돌합니다. 이 모드, 동시 실행되는 ACCESS SHARE만을 허가합니다. 즉, 이 락 모드를 가지는 트랜잭션과 병행해서 실행할 수 있는 처리는 테이블의 read 뿐입니다.
유저 테이블에 대해 이 락 모드를 자동으로 획득하는PostgreSQL커멘드는 없습니다. 그러나 이는 일부 연산 내, 특정 시스템 카탈로그에서 획득됩니다.
모든 락 모드(ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, 및 ACCESS EXCLUSIVE)와 충돌합니다. 이 모드에 의해, 그 보관 유지자 이외에 테이블에 접근하는 트랜잭션이 없다는 것이 보증됩니다.
ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER 및 VACUUM FULL커멘드에 의해 획득됩니다. 또한, 명시적으로 모드를 지정하지 않으면, 이것이 LOCK TABLE문을 사용할 때의 디폴트 락 모드입니다.
Tip: ACCESS EXCLUSIVE락만이, SELECT(FOR UPDATE/SHARE없음) 문을 차단합니다.
보통 락은 한번 획득하면, 트랜잭션의 마지막까지 소유됩니다. 그러나 락이 세이브 포인트의 확립 후에 획득됐을 경우, 세이브 포인트가 롤백(rollback)되면, 락은 즉석에서 해제됩니다. 이것은, ROLLBACK가 세이브 포인트 이후에 행해진 모든 커멘드의 효과를 취소한다는 원칙과 일관성을 가집니다. PL/pgSQL예외 블록 내에서 획득된 락에 대해서도 마찬가집니다 그 블록으로부터 에러로 빠진 후, 획득된 락은 해제됩니다.
테이블 레벨 락에 가세해, 배타 락 또는 공유 락을 실시할 수 있는, 행 레벨 락이 있습니다. 특정 행에 대한 행 레벨의 배타 락은, 행이 갱신 또는 삭제될 때 자동으로 획득됩니다. 트랜잭션이 처리 또는 롤백(rollback) 될 때까지, 테이블 레벨 락과 같이, 락은 소유되어집니다. 행 레벨 락은 데이터 쿼리에는 영향을 주지 않습니다. 행 레벨 락은 같은 행에 대한 입력 만을 차단합니다.
실제로 행을 변경하지 않고 행에 대해 행 레벨 락을 획득하려면, 해당하는 행을 SELECT FOR UPDATE로 선택해 주십시요. 일단 행 레벨 락이 획득되면, 충돌에 대한 걱정없이, 트랜잭션은 여러 번의 행 변경이 가능하다는 것을 주의하십시요.
어느 행에 대한 공유된 행 레벨 락을 획득하려면, SELECT FOR SHARE를 사용해 해당되는 행을 선택해 주십시요. 공유 락은, 다른 트랜잭션에 의한 같은 공유 락의 획득을 방해하지 않습니다. 그러나 다른 트랜잭션이 공유 락을 가진 행에 대해서, 갱신, 삭제, 배타 락의 획득을 실행할 수 있도록 하는 트랜잭션은 없습니다. 이것을 시험하면, 공유 락이 해제될 때까지 차단됩니다.
PostgreSQL에서는, 메모리상에서 변경된 행의 정보를 기억하지 않으므로, 동시에 잠글 수 있는 행 수의 상한은 없습니다. 그러나 행을 잠글 때, 디스크에 입력하는 작업이 발생할지도 모릅니다. 따라서, 예를 들면SELECT FOR UPDATE는 선택된 행이 락된 것을 표시하기 위해 변경하고 디스크에 결과를 입력합니다.
테이블과 행 락에 가세해 페이지 레벨의 공유/배타 락이 있으며, 이들은 공유 버퍼 풀에 있는 테이블 페이지의 읽고 쓰기 액세스를 관리하기 위해서 사용됩니다. 이러한 락은 행이 취득된 후나 갱신된 후 즉시 해제됩니다. 어플리케이션 개발자는 보통 페이지 레벨 락을 고려할 필요는 없습니다. 락에 대해 완벽하게 설명하고 싶어 페이지 레벨 락을 설명했습니다.
명시적 락의 사용은 데드 락의 원인이 될 가능성이 있습니다. 데드 락이란, 2개(혹은 그 이상)의 트랜잭션에서, 각각의 트랜잭션이 필요로 하는 락을 소유해 버리는 것입니다. 예를 들면, 트랜잭션 1이 테이블 A에 배타 락을 획득하고 있고, 그런 다음에 테이블 B가 배타 락을 획득하거나 반면에, 트랜잭션 2가 이미 테이블 B에 배타 락을 획득이 끝난 상태이며, 지금부터 테이블 A에 배타 락을 원하면, 어느 쪽의 트랜잭션도 처리되지 않습니다. PostgreSQL에서는 자동으로 데드 락 상황을 감지해, 관계하는 트랜잭션의 하나를 중단(abort)시키는 것으로 상황을 해결하고 다른 하나의 트랜잭션 처리를 완료시킵니다 (어느 트랜잭션을 중단(abort)할까를 정확하게 예측하기는 힘들며, 이에 의존해지 말아야합니다.).
데드 락은 행 레벨 락의 결과로서 발생할 가능성이 있습니다 (따라서, 명시적 락 처리를 사용하지 않아도 발생할 가능성이 있습니다). 2개 동시 트랜잭션이 있는 테이블을 변경하는 상황을 생각해 보겠습니다. 1 번째 트랜잭션은 이하를 실행합니다.
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;
이는 지정한 계좌 번호의 행에 대해, 행 레벨 락을 획득합니다. 다음으로 2번째 트랜잭션이 이하를 실행합니다.
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222; UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;
1번째 UPDATE문은 지정된 행에 대해 행 레벨 락의 획득에 성공하고, 행의 갱신도 성공합니다. 그러나 2번째 UPDATE문은 갱신 대상의 행이 락된 것을 발견하고, 락을 획득한 트랜잭션이 완료할 때까지 대기합니다. 트랜잭션 2는 계속해서 실행하기 전에 트랜잭션 1이 완료하길 기대하고 있습니다. 그런데 트랜잭션 1이 여기서 이하를 실행합니다.
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
트랜잭션 1은 지정한 행의 행 레벨 락을 획득하려고 하지만, 불가능합니다. 트랜잭션 2가 락을 이미 획득하고 있기 때문입니다. 그 때문에 트랜잭션 2가 완료할 때까지 대기합니다. 이렇게 트랜잭션 1은 트랜잭션 2로 차단되고 트랜잭션 2는 트랜잭션 1에 차단되는 데드 락 상태입니다. PostgreSQL는 데드 락 상태를 발견하고 다른 한쪽의 트랜잭션을 중단시킵니다.
데드 락을 막는 가장 좋은 방법은, 데이터베이스를 사용하는 모든 어플리케이션이, 일관된 순서로 복수의 오브젝트에 대한 락을 획득하는 것입니다. 전에 나타낸 데드 락의 예로, 양쪽 모두의 트랜잭션이 같은 순서로 행을 갱신한다면, 데드 락은 일어나지 않습니다. 또한, 트랜잭션 내의 오브젝트에 획득되어진 최초의 락은 오브젝트가 필요로 하는 최상의 모드라는 것을 확실히 보증해야 합니다. 이것을 사전에 검증할 수 없을 때, 데드 락으로 중단(abort)된 트랜잭션을 재실행하면, 데드 락은 데이터베이스를 가동시켜도 처리되어 집니다.
데드 락 상황이 발견되지 않으면, 테이블 레벨 락이나 행 레벨 락을 요구하는 트랜잭션은 충돌하는 락이 해제될 때까지, 무한정 대기합니다. 따라서, 어플리케이션에서 장시간(예를 들면, 유저의 입력 대기) 트랜잭션을 연 채로 유지하는 것은 추천되지 않습니다.
PostgreSQL는 어플리케이션에서 개별적 의미를 가지는 락을 생성하는 방법을 제공합니다. 이는 권고적 락으로 불립니다. 왜냐하면 시스템은 그들의 사용을 강요하지 않기 때문입니다. 즉, 어플리케이션이 이들을 정확하게 쓰는 가에 달려있습니다. 권고적 락은 MVCC 방식에 맞추기 힘든 락 전략임에도, 유용하게 사용할 수 있습니다. 권고적 락을 획득한 후, 명시적으로 해제되어 세션이 끝날 때까지, 락이 소유되어집니다. 표준 락과 달리, 권고적 락은 트랜잭션에 의미를 부여하지 않습니다. 락이 트랜잭션 중에 획득되어 다음에 롤백(rollback)됐다고 해도, 롤백(rollback) 후에도 소유되어집니다. 그리고 호출한 트랜잭션이 다음에 실패했다고 해도 락 해제는 유효합니다. 소유하는 프로세스에서 동일한 락을 여러 차례 획득할 수도 있습니다. 이 경우, 개개의 락 요구에 대해서, 락을 실제로 해제하기 전에 대응하는 락 해제 요구가 없으면 안됩니다. (이미 세션이 지정된 락을 소유하고 있는 경우, 다른 세션이 그 락 획득을 대기하고 있었다고 해도, 추가의 요구는 항상 성공합니다. ) 모든 PostgreSQL의 락과 같이, 임의의 세션으로 현재 보관 유지되고 있는 권고적 락은 모두, pg_locks 시스템 뷰로 열거되고 있습니다.
권고적 락은 공유 메모리 풀의 외부에 할당될 수 있어 그 용량은max_locks_per_transaction과max_connections설정 변수에 의해 결정됩니다. 이 메모리가 낭비하지 않도록 주의가 필요합니다. 그렇지 않으면, 서버는 락 획득을 전혀 허가할 수가 없게 됩니다. 이는 서버로 허가할 수 있는 권고적 락 수에 상한이 있다는 것을 의미합니다. 서버의 설정에 따라 다르지만, 보통 1만에서 10만 정도가 됩니다.
일반적인 권고적 락의 사용 방법은, 자주 "플랫 파일"데이터 관리 시스템으로 불리는, 비관적인 락 전략을 이뮬레이트하는 것입니다. 같은 목적을 위해 테이블 내에 플래그를 저장할 수도 있지만, 권고적 락이 빠르게 MVCC의 팽창을 막을 수 있습니다. 또한, 세션 종료시에 서버에 의한 자동 정리를 실시할 수도 있습니다. SQL 표현식의 평가 순서라고 하는 점으로부터, 이 방법을 확실히 사용하는 상황, 특히 명시적인 순서나 LIMIT구를 가지는 쿼리는 락 획득을 주의해서 제어하도록 하십시요. 이하에 예를 나타냅니다.
SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger! SELECT pg_advisory_lock(q.id) FROM ( SELECT id FROM foo WHERE id > 12345 LIMIT 100; ) q; -- ok
위의 예에서는, 락 획득 함수가 실행되기 전에LIMIT 가 적용된다는 것을 보장할 수 없기 때문에, 2번째의 형식은 위험합니다. 이로 인해, 어플리케이션이 예상되지 않는다라는 요구로부터 락이 생성될 가능성이 있습니다. 그 때문에 (세션이 종료할 때까지) 해제에 실패하게 됩니다. 어플리케이션의 뷰에서 보면, 이러한 락은 단순한 장식입니다만, pg_locks로부터는 계속 보여집니다.
권고적 락을 취급하기 위한 함수에 대한 사항은 Table 9-50에서 설명합니다.