Postgres 잠금 관리자 잠금 해제. 브루스 몸지안

Bruce Momjian의 2020년 강연 "Postgres 잠금 관리자 잠금 해제"의 내용입니다.

(참고: 슬라이드의 모든 SQL 쿼리는 다음 링크에서 얻을 수 있습니다. http://momjian.us/main/writings/pgsql/locking.sql)

안녕하세요! 여기 러시아에 다시 오게 되어 반갑습니다. 작년에 못가서 아쉽지만 올해 Ivan과 저는 큰 계획이 있어요. 나는 여기에 훨씬 더 자주 있기를 바랍니다. 나는 러시아에 오는 것을 좋아합니다. 트베리의 튜멘을 방문하겠습니다. 나는 이 도시들을 방문할 수 있게 되어 매우 기쁩니다.

제 이름은 브루스 맘지안입니다. 저는 EnterpriseDB에서 일하고 있으며 23년 넘게 Postgres를 사용해 왔습니다. 저는 미국 필라델피아에 살고 있습니다. 저는 일년에 90일 정도 여행을 합니다. 그리고 저는 40개 정도의 컨퍼런스에 참석합니다. 나의 벡 사이트, 여기에는 지금 보여드릴 슬라이드가 포함되어 있습니다. 따라서 컨퍼런스가 끝난 후 제 개인 웹사이트에서 다운로드하실 수 있습니다. 또한 약 30개의 프레젠테이션이 포함되어 있습니다. 또한 비디오와 500개가 넘는 많은 블로그 항목이 있습니다. 이것은 상당히 유익한 리소스입니다. 이 자료에 관심이 있으시면 꼭 사용해 보시기 바랍니다.

저는 Postgres를 사용하기 전에 교사이자 교수였습니다. 그리고 이제 제가 말하려는 내용을 여러분에게 말할 수 있게 되어 매우 기쁩니다. 이것은 나의 가장 흥미로운 프레젠테이션 중 하나입니다. 그리고 이 프레젠테이션에는 110개의 슬라이드가 포함되어 있습니다. 우리는 간단한 것부터 이야기하기 시작할 것이고, 결국 보고서는 점점 더 복잡해지고 상당히 복잡해질 것입니다.

이것은 다소 불쾌한 대화입니다. 차단은 가장 인기 있는 주제가 아닙니다. 우리는 이것이 어딘가에서 사라지기를 원합니다. 치과에 가는 것과 같습니다.

1. 잠금은 데이터베이스에서 작업하고 동시에 여러 프로세스를 실행하는 많은 사람들에게 문제입니다. 차단이 필요합니다. 즉, 오늘은 차단에 대한 기본 지식을 알려드리겠습니다.
2. 거래 ID. 이것은 프레젠테이션에서 다소 지루한 부분이지만 이해해야 합니다.
3. 다음으로 차단 유형에 대해 이야기하겠습니다. 이것은 상당히 기계적인 부분입니다.
4. 아래에는 차단에 대한 몇 가지 예가 나와 있습니다. 그리고 그것은 이해하기 매우 어려울 것입니다.

차단에 대해 이야기해보겠습니다.

우리의 용어는 상당히 복잡합니다. 이 구절이 어디서 나온 것인지 아는 사람이 얼마나 됩니까? 두 사람. Colossal Cave Adventure라는 게임에서 나온 내용입니다. 80년대에는 텍스트 기반의 컴퓨터 게임이었던 것 같아요. 그곳에서 동굴로, 미로로 들어가야 했는데, 텍스트는 바뀌었지만 내용은 매번 거의 같았습니다. 저는 이 게임을 그렇게 기억합니다.

그리고 여기서 우리는 Oracle에서 우리에게 온 잠금의 이름을 볼 수 있습니다. 우리는 그것들을 사용합니다.

여기서 우리는 나를 혼란스럽게 하는 용어를 봅니다. 예를 들어 SHARE UPDATE ECXLUSIVE입니다. 다음 RAW ECXLUSIVE를 공유하세요. 솔직히 말해서, 이 이름들은 그다지 명확하지 않습니다. 우리는 그것들을 더 자세히 고려하려고 노력할 것입니다. 일부에는 분리를 의미하는 "공유"라는 단어가 포함되어 있습니다. 일부에는 "독점"이라는 단어가 포함되어 있습니다. 일부에는 이 두 단어가 모두 포함되어 있습니다. 저는 이 자물쇠가 어떻게 작동하는지부터 시작하고 싶습니다.

그리고 '액세스'라는 단어도 매우 중요합니다. 그리고 "row"라는 단어는 문자열입니다. 즉, 액세스 분산, 행 분산입니다.

안타깝게도 Postgres에서 이해해야 할 또 다른 문제는 MVCC입니다. 안타깝게도 제 강연에서는 다루지 못할 것입니다. 내 웹사이트에 이 주제에 대한 별도의 프레젠테이션이 있습니다. 그리고 이 프레젠테이션이 어렵다고 생각하신다면 아마도 MVCC가 제겐 가장 어려울 것 같습니다. 그리고 관심이 있으시면 웹사이트에서 시청하실 수 있습니다. 영상을 보실 수 있습니다.

우리가 이해해야 할 또 다른 사항은 거래 ID입니다. 많은 거래는 고유 식별자 없이는 작동할 수 없습니다. 그리고 여기에 거래가 무엇인지에 대한 설명이 있습니다. Postgres에는 두 가지 트랜잭션 번호 지정 시스템이 있습니다. 나는 이것이 그다지 좋은 해결책이 아니라는 것을 알고 있습니다.

또한 슬라이드는 이해하기 상당히 어려울 수 있으므로 빨간색으로 강조 표시된 부분이 주의가 필요한 부분이라는 점을 명심하세요.

http://momjian.us/main/writings/pgsql/locking.sql

어디 보자. 거래 번호가 빨간색으로 강조 표시됩니다. SELECT pg_back 함수가 여기에 표시됩니다. 내 거래와 거래 ID를 반환합니다.

한 가지 더, 이 프리젠테이션이 마음에 들고 데이터베이스에서 실행하고 싶다면 분홍색 링크로 이동하여 이 프리젠테이션에 대한 SQL을 다운로드할 수 있습니다. PSQL에서 간단히 실행하면 전체 프레젠테이션이 화면에 즉시 표시됩니다. 꽃은 포함되지 않지만 적어도 우리는 그것을 볼 수 있습니다.

이 경우 거래 ID가 표시됩니다. 이것은 우리가 그녀에게 할당한 번호입니다. 그리고 Postgres에는 가상 트랜잭션 ID라고 하는 또 다른 유형의 트랜잭션 ID가 있습니다.

그리고 우리는 이것을 이해해야 합니다. 이것은 매우 중요합니다. 그렇지 않으면 Postgres의 잠금을 이해할 수 없습니다.

가상 트랜잭션 ID는 지속적인 값을 포함하지 않는 트랜잭션 ID입니다. 예를 들어, SELECT 명령을 실행하면 데이터베이스를 변경하지 않고 아무 것도 잠그지 않을 것입니다. 따라서 간단한 SELECT를 실행할 때 해당 트랜잭션에 영구 ID를 제공하지 않습니다. 우리는 그곳에서 그녀에게 가상 ID만 제공합니다.

이는 Postgres 성능을 향상시키고 정리 기능을 향상시키므로 가상 트랜잭션 ID는 두 개의 숫자로 구성됩니다. 슬래시 앞의 첫 번째 숫자는 백엔드 ID입니다. 그리고 오른쪽에는 카운터만 보입니다.

따라서 요청을 실행하면 백엔드 ID가 2라고 표시됩니다.

그리고 이러한 일련의 트랜잭션을 실행하면 쿼리를 실행할 때마다 카운터가 증가하는 것을 볼 수 있습니다. 예를 들어 2/10, 2/11, 2/12 등의 쿼리를 실행하면

여기에는 두 개의 열이 있다는 점을 명심하세요. 왼쪽에는 가상 거래 ID(2/12)가 표시됩니다. 오른쪽에는 영구 거래 ID가 있습니다. 그리고 이 필드는 비어 있습니다. 그리고 이 트랜잭션은 데이터베이스를 수정하지 않습니다. 그래서 영구 거래 ID를 제공하지 않습니다.

분석 명령((ANALYZE))을 실행하자마자 동일한 쿼리가 영구 트랜잭션 ID를 제공합니다. 이것이 우리에게 어떻게 변했는지 보세요. 이전에는 이 ID가 없었으나 지금은 있습니다.

여기 또 다른 요청, 또 다른 거래가 있습니다. 가상거래번호는 2/13 입니다. 그리고 영구 트랜잭션 ID를 요청하면 쿼리를 실행할 때 이를 얻게 됩니다.

그럼, 한 번 더. 가상 거래 ID와 영구 거래 ID가 있습니다. Postgres 동작을 이해하려면 이 점을 이해하십시오.

세 번째 섹션으로 넘어갑니다. 여기서는 Postgres의 다양한 잠금 유형을 살펴보겠습니다. 그다지 흥미롭지 않습니다. 마지막 섹션은 훨씬 더 흥미로울 것입니다. 그러나 우리는 기본적인 것들을 고려해야 합니다. 그렇지 않으면 다음에 무슨 일이 일어날지 이해하지 못할 것이기 때문입니다.

이 섹션을 살펴보면서 각 유형의 잠금 장치를 살펴보겠습니다. 그리고 설치 방법과 작동 방식에 대한 예를 보여주고 Postgres에서 잠금이 어떻게 작동하는지 확인하는 데 사용할 수 있는 몇 가지 쿼리도 보여 드리겠습니다.

쿼리를 생성하고 Postgres에서 무슨 일이 일어나고 있는지 확인하려면 시스템 보기에서 쿼리를 실행해야 합니다. 이 경우 pg_lock은 빨간색으로 강조 표시됩니다. Pg_lock은 현재 Postgres에서 사용 중인 잠금이 무엇인지 알려주는 시스템 테이블입니다.

그러나 pg_lock 자체는 매우 복잡하기 때문에 보여드리기가 매우 어렵습니다. 그래서 pg_locks를 보여주는 뷰를 만들었습니다. 그리고 그것은 또한 내가 더 잘 이해할 수 있게 해주는 몇 가지 작업을 수행합니다. 즉, 내 잠금, 내 세션 등을 제외합니다. 이는 단지 표준 SQL일 뿐이며 무슨 일이 일어나고 있는지 더 잘 보여줄 수 있습니다.

또 다른 문제는 이 보기가 매우 넓기 때문에 두 번째 보기인 lockview2를 만들어야 한다는 것입니다.

그리고 테이블의 더 많은 열이 표시됩니다. 그리고 나머지 열을 보여주는 또 다른 하나입니다. 내용이 꽤 복잡해서 최대한 간단하게 설명하려고 노력했습니다.

그래서 우리는 Lockdemo라는 테이블을 만들었습니다. 그리고 거기에 한 줄을 만들었습니다. 이것이 우리의 샘플 테이블입니다. 그리고 우리는 자물쇠의 예를 보여주기 위해 섹션을 만들 것입니다.

즉, 행 하나, 열 하나입니다. 첫 번째 유형의 잠금은 ACCESS SHARE입니다. 이는 가장 제한이 적은 차단입니다. 이는 실제로 다른 잠금 장치와 충돌하지 않음을 의미합니다.

그리고 명시적으로 잠금을 정의하려면 "lock table" 명령을 실행합니다. 그러면 분명히 차단됩니다. 즉, ACCESS SHARE 모드에서는 잠금 테이블을 시작합니다. 그리고 백그라운드에서 PSQL을 실행하면 이런 방식으로 첫 번째 세션에서 두 번째 세션을 시작합니다. 즉, 여기서 무엇을 할 것인가? 나는 다른 세션으로 가서 "이 요청에 대한 잠금 보기를 보여주세요"라고 말합니다. 그리고 여기 이 테이블에는 AccessShareLock이 있습니다. 제가 요청한 것이 바로 이것이었습니다. 그리고 그는 블록이 할당되었다고 말합니다. 매우 간단합니다.

또한 두 번째 열을 보면 거기에는 아무것도 없습니다. 그것들은 비어 있습니다.

그리고 "SELECT" 명령을 실행하면 이는 AccessShareLock을 요청하는 암시적(명시적) 방법입니다. 그래서 테이블을 해제하고 쿼리를 실행하면 쿼리가 여러 행을 반환합니다. 그리고 줄 중 하나에 AccessShareLock이 표시됩니다. 따라서 SELECT는 테이블에서 AccessShareLock을 호출합니다. 그리고 낮은 수준의 잠금이기 때문에 사실상 어떤 것과도 충돌하지 않습니다.

SELECT를 실행하고 세 개의 서로 다른 테이블이 있으면 어떻게 되나요? 이전에는 하나의 테이블만 실행했지만 이제는 pg_class, pg_namespace 및 pg_attribute의 세 개를 실행하고 있습니다.

이제 쿼리를 보면 9개의 테이블에 XNUMX개의 AccessShareLock이 있습니다. 왜? 세 개의 테이블(pg_attribute, pg_class, pg_namespace)이 파란색으로 강조 표시되어 있습니다. 그러나 이러한 테이블을 통해 정의된 모든 인덱스에도 AccessShareLock이 있음을 알 수 있습니다.

그리고 이것은 실제로 다른 사람과 충돌하지 않는 자물쇠입니다. 그리고 그것이 하는 일은 단순히 테이블을 선택하는 동안 테이블을 재설정하는 것을 방지하는 것뿐입니다. 말된다. 즉, 테이블을 선택하면 그 순간 사라지는데 이는 잘못된 것이므로 AccessShare는 "작업하는 동안 이 테이블을 떨어뜨리지 마세요"라고 알려주는 낮은 수준의 잠금입니다.. 본질적으로 그것이 그녀가 하는 전부입니다.

ROW SHARE - 이 잠금은 약간 다릅니다.

예를 들어 보겠습니다. SELECT ROW SHARE 각 행을 개별적으로 잠그는 방식. 이렇게 하면 우리가 시청하는 동안 누구도 삭제하거나 변경할 수 없습니다.

그렇다면 SHARE LOCK은 무엇을 할까요? SELECT의 트랜잭션 ID는 681입니다. 그리고 이것은 흥미롭습니다. 여기 뭔 일 있었 니? 숫자가 처음으로 표시되는 것은 "잠금" 필드에 있습니다. 우리는 트랜잭션 ID를 가져왔고 독점 모드에서 이를 차단하고 있다고 말합니다. 그것이 하는 일은 테이블 어딘가에 기술적으로 잠겨 있는 행이 있다는 것입니다. 그러나 그는 정확히 어디인지는 말하지 않습니다. 이에 대해서는 잠시 후에 더 자세히 살펴보겠습니다.

여기서 우리는 자물쇠가 우리에 의해 사용된다고 말합니다.

따라서 배타적 잠금은 명시적으로 배타적임을 나타냅니다. 또한 이 테이블에서 행을 삭제하면 보시다시피 이런 일이 발생합니다.

SHARE EXCLUSIVE는 더 긴 잠금입니다.

이것은 사용될 (ANALYZE) 분석기 명령입니다.

SHARE LOCK – 공유 모드에서 명시적으로 잠글 수 있습니다.

고유 인덱스를 생성할 수도 있습니다. 그리고 그 일부인 SHARE LOCK을 볼 수 있습니다. 그리고 테이블을 잠그고 SHARE LOCK을 설정합니다.

기본적으로 테이블의 SHARE LOCK은 다른 사람이 테이블을 읽을 수는 있지만 수정할 수는 없음을 의미합니다. 이것이 바로 고유 인덱스를 생성할 때 발생하는 현상입니다.

고유한 동시 인덱스를 생성하면 다른 유형의 잠금을 사용하게 됩니다. 기억하는 것처럼 동시 인덱스를 사용하면 잠금 요구 사항이 줄어들기 때문입니다. 그리고 일반 잠금, 일반 인덱스를 사용하면 테이블 인덱스가 생성되는 동안 테이블 인덱스에 쓰는 것을 방지할 수 있습니다. 동시 인덱스를 사용하는 경우 다른 유형의 잠금을 사용해야 합니다.

SHARE ROW EXCLUSIVE - 명시적으로(명시적으로) 설정할 수 있습니다.

또는 규칙을 만들 수도 있습니다. 즉, 규칙이 사용될 특정 사례를 취합니다.

EXCLUSIVE 잠금은 다른 사람이 테이블을 변경할 수 없음을 의미합니다.

여기에서는 다양한 유형의 잠금 장치를 볼 수 있습니다.

예를 들어 ACCESS EXCLUSIVE는 차단 명령입니다. 예를 들어, 다음과 같이 하면 CLUSTER table, 그러면 아무도 거기에 글을 쓸 수 없다는 것을 의미합니다. 그리고 테이블 자체뿐만 아니라 인덱스도 잠급니다.

이것은 ACCESS EXCLUSIVE 차단의 두 번째 페이지로, 테이블에서 차단하는 내용을 정확히 볼 수 있습니다. 이는 개별 테이블 행을 잠그는데 이는 매우 흥미롭습니다.

이것이 제가 제공하고 싶은 모든 기본 정보입니다. 우리는 잠금, 트랜잭션 ID, 가상 트랜잭션 ID, 영구 트랜잭션 ID에 대해 이야기했습니다.

이제 몇 가지 차단 사례를 살펴보겠습니다. 이것이 가장 흥미로운 부분입니다. 우리는 매우 흥미로운 사례를 살펴볼 것입니다. 이 프레젠테이션의 목표는 Postgres가 특정 항목을 차단하려고 할 때 실제로 무엇을 하는지 더 잘 이해할 수 있도록 하는 것입니다. 나는 그가 부분을 차단하는 데 매우 능숙하다고 생각합니다.

몇 가지 구체적인 예를 살펴보겠습니다.

테이블과 테이블의 한 행부터 시작하겠습니다. 무언가를 삽입하면 테이블에 ExclusiveLock, Transaction ID 및 ExclusiveLock이 표시됩니다.

행을 두 개 더 삽입하면 어떻게 되나요? 이제 테이블에는 세 개의 행이 있습니다. 그리고 한 행을 삽입하고 이를 출력으로 얻었습니다. 그리고 두 개의 행을 더 삽입하면 무엇이 이상한가요? 이상한 점은 이 테이블에 세 개의 행을 추가했지만 잠금 테이블에는 여전히 두 개의 행이 있기 때문입니다. 이것이 본질적으로 Postgres의 기본 동작입니다.

많은 사람들은 데이터베이스에서 100개의 행을 잠그면 100개의 잠금 항목을 생성해야 한다고 생각합니다. 한 번에 1개의 행을 차단하려면 해당 쿼리가 000개 필요합니다. 그리고 차단하려면 백만 또는 수십억이 필요합니다. 하지만 이렇게 하면 별로 효과가 없을 것입니다. 각 개별 행에 대해 차단 항목을 생성하는 시스템을 사용한 경우 이것이 복잡하다는 것을 알 수 있습니다. 오버플로가 가능한 잠금 테이블을 즉시 정의해야 하는데 Postgres는 그렇게 하지 않기 때문입니다.

그리고 이 슬라이드에서 정말 중요한 점은 개별 행을 잠그는 MVCC 내부에서 실행되는 또 다른 시스템이 있음을 명확하게 보여 준다는 것입니다. 따라서 수십억 개의 행을 잠그면 Postgres는 수십억 개의 별도 잠금 명령을 생성하지 않습니다. 그리고 이는 생산성에 매우 좋은 영향을 미칩니다.

업데이트는 어떻습니까? 지금 행을 업데이트하고 있는데 한 번에 두 가지 다른 작업을 수행한 것을 볼 수 있습니다. 동시에 테이블을 잠그는 동시에 인덱스도 잠겼습니다. 그리고 이 테이블에는 고유 제약 조건이 있기 때문에 인덱스를 잠가야 했습니다. 그리고 누구도 이를 변경하지 못하도록 차단하고 있습니다.

두 행을 업데이트하고 싶으면 어떻게 되나요? 그리고 우리는 그가 같은 방식으로 행동하는 것을 봅니다. 우리는 두 배의 업데이트를 수행하지만 잠금 라인 수는 정확히 동일합니다.

Postgres가 이를 어떻게 수행하는지 궁금하다면 Postgres가 내부적으로 이러한 행의 변경 사항을 표시하는 방법을 알아보려면 MVCC에 대한 내 강연을 들어야 합니다. Postgres에는 이를 수행하는 방법이 있지만 테이블 잠금 수준에서 수행하는 것이 아니라 더 낮고 효율적인 수준에서 수행합니다.

무언가를 삭제하고 싶다면 어떻게 해야 하나요? 예를 들어, 한 행을 삭제했는데 여전히 두 개의 차단 입력이 있고, 모두 삭제하고 싶어도 여전히 그대로 남아 있습니다.

예를 들어 1줄을 삽입한 다음 000줄을 삭제하거나 추가하고 싶을 때 추가하거나 변경한 개별 줄은 여기에 기록되지 않습니다. 시리즈 자체 내에서 더 낮은 수준으로 작성되었습니다. 그리고 MVCC 연설에서 이에 대해 자세히 이야기했습니다. 그러나 잠금을 분석할 때 테이블 수준에서 잠기고 있는지 확인하고 여기에 개별 행이 기록되는 방식을 확인하지 않는 것이 매우 중요합니다.

명시적 차단은 어떻습니까?

새로 고침을 클릭하면 두 개의 행이 잠깁니다. 모두 선택하고 "모든 곳에서 업데이트"를 클릭하면 여전히 두 개의 차단 기록이 있습니다.

각 개별 행에 대해 별도의 레코드를 생성하지 않습니다. 그러면 생산성이 떨어지기 때문에 생산성이 너무 높아질 수 있습니다. 그리고 우리는 불쾌한 상황에 처하게 될 수도 있습니다.

그리고 마찬가지로, 공유한다면 30번 모두 할 수 있습니다.

테이블을 복원하고 모든 것을 삭제한 다음 한 행을 다시 삽입합니다.

매우 잘 알려져 있고 원하는 동작인 Postgres에서 볼 수 있는 또 다른 동작은 업데이트 또는 선택을 수행할 수 있다는 것입니다. 그리고 당신은 이것을 동시에 할 수 있습니다. 그리고 선택은 업데이트와 반대 방향의 동일한 작업을 차단하지 않습니다. 우리는 독자에게 작가를 막지 말라고 말하고, 작가는 독자를 막지 않았습니다.

이에 대한 예를 보여 드리겠습니다. 나는 이제 선택을 하겠다. 그런 다음 INSERT를 수행합니다. 그러면 - 694를 볼 수 있습니다. 이 삽입을 수행한 트랜잭션의 ID를 볼 수 있습니다. 그리고 그것이 작동하는 방식입니다.

그리고 지금 내 백엔드 ID를 보면 695입니다.

그리고 내 테이블에 695가 나타나는 것을 볼 수 있습니다.

여기서 이렇게 업데이트하면 다른 사례가 발생합니다. 이 경우 695는 배타적 잠금이고 업데이트는 동일한 동작을 갖지만 둘 사이에 충돌이 발생하지 않는 것은 매우 특이한 현상입니다.

그리고 상단에는 ShareLock, 하단에는 ExclusiveLock인 것을 확인할 수 있습니다. 그리고 두 거래가 모두 성공했습니다.

그리고 이것이 어떻게 일어나는지 이해하려면 MVCC에서 제가 하는 강연을 들어야 합니다. 그러나 이는 동시에 수행할 수 있다는 예입니다. 즉, SELECT와 UPDATE를 동시에 수행할 수 있습니다.

재설정하고 작업을 한 번 더 수행해 보겠습니다.

동일한 행에서 두 개의 업데이트를 동시에 실행하려고 하면 차단됩니다. 그리고 기억하세요, 독자가 작가를 막는 것이 아니고, 작가가 독자를 막는 것이 아니라 한 작가가 다른 작가를 막는다고 했습니다. 즉, 두 사람이 동시에 동일한 행을 업데이트하도록 할 수 없습니다. 둘 중 하나가 끝날 때까지 기다려야 합니다.

이를 설명하기 위해 Lockdemo 테이블을 살펴보겠습니다. 그리고 한 행을 살펴보겠습니다. 거래당 698.

이를 2로 업데이트했습니다. 699가 첫 번째 업데이트입니다. 성공했거나 거래가 보류 중이며 확인 또는 취소를 기다리고 있습니다.

하지만 다른 것을 보세요. 2/51이 첫 번째 거래이자 첫 번째 세션입니다. 3/112는 해당 값을 3으로 변경한 맨 위의 두 번째 요청입니다. 그리고 알다시피 맨 위의 요청은 699로 자체적으로 잠겼습니다. 그러나 3/112는 잠금을 허용하지 않았습니다. Lock_mode 열은 기다리고 있는 내용을 나타냅니다. 699를 예상하고 있습니다. 그리고 699가 어디 있는지 보면 더 높습니다. 그리고 첫 번째 세션은 무엇을 했나요? 그녀는 자신의 거래 ID에 대한 독점 잠금을 만들었습니다. 이것이 Postgres가 수행하는 방식입니다. 자체 거래 ID를 차단합니다. 그리고 누군가가 확인하거나 취소할 때까지 기다리려면 보류 중인 거래가 있는 동안 기다려야 합니다. 그래서 우리는 이상한 선을 볼 수 있습니다.

다시 살펴보겠습니다. 왼쪽에는 처리 ID가 표시됩니다. 두 번째 열에는 가상 트랜잭션 ID가 표시되고 세 번째 열에는 lock_type이 표시됩니다. 이것은 무엇을 의미 하는가? 본질적으로 그것이 말하는 것은 거래 ID를 차단하고 있다는 것입니다. 하지만 맨 아래의 모든 행에는 관계가 표시되어 있습니다. 그래서 테이블에는 두 가지 유형의 자물쇠가 있습니다. 관계 잠금이 있습니다. 그리고 나서 스스로 차단하는 transactionid 차단이 있는데, 이는 정확히 첫 번째 행이나 transactionid가 있는 맨 아래에서 발생하며 699가 작업을 완료할 때까지 기다립니다.

여기서 무슨 일이 일어나는지 볼게요. 그리고 여기서는 두 가지 일이 동시에 일어납니다. 첫 번째 행에서 자체적으로 잠기는 트랜잭션 ID 잠금을 보고 있습니다. 그리고 그녀는 사람들을 기다리게 하기 위해 자신을 차단합니다.

6번째 줄을 보시면 첫번째와 같은 항목입니다. 따라서 트랜잭션 699가 차단됩니다. 700은 자동 잠금 기능도 있습니다. 그리고 맨 아래 행에는 699가 작업을 완료할 때까지 기다리고 있는 것을 볼 수 있습니다.

그리고 lock_type 튜플에는 숫자가 표시됩니다.

0/10임을 알 수 있습니다. 이는 페이지 번호이자 이 특정 행의 오프셋입니다.

그리고 업데이트하면 0/11이 되는 것을 볼 수 있습니다.

하지만 실제로는 0/10입니다. 왜냐하면 이 작업에 대한 대기 시간이 있기 때문입니다. 이것이 제가 확인을 기다리고 있는 시리즈임을 확인할 기회가 있습니다.

이를 확인하고 커밋을 누른 후 업데이트가 완료되면 이것이 다시 표시됩니다. 트랜잭션 700은 유일한 잠금이며 커밋되었기 때문에 다른 사람을 기다리지 않습니다. 단순히 트랜잭션이 완료될 때까지 기다립니다. 699가 소진되면 더 이상 아무것도 기다리지 않습니다. 이제 트랜잭션 700은 모든 것이 정상이며 허용된 모든 테이블에 필요한 모든 잠금이 있다고 말합니다.

그리고 이 모든 것을 더욱 복잡하게 만들기 위해 이번에는 계층 구조를 제공할 또 다른 뷰를 만듭니다. 나는 당신이 이 요청을 이해하리라 기대하지 않습니다. 하지만 이를 통해 우리는 무슨 일이 일어나고 있는지 더 명확하게 알 수 있습니다.

이는 다른 섹션도 포함하는 재귀 뷰입니다. 그러면 모든 것이 다시 하나로 합쳐집니다. 이것을 활용해보자.

3개의 동시 업데이트를 수행하고 행이 이제 4개라고 말하면 어떻게 될까요? 그리고 XNUMX을 XNUMX로 변경하겠습니다.

여기에 4가 표시됩니다. 트랜잭션 ID는 702입니다.

그리고 4를 5로 바꾸겠습니다. 그리고 5를 6으로, 6을 7로 바꾸겠습니다. 그리고 이 하나의 거래가 끝나기를 기다리고 있을 여러 사람을 줄을 서겠습니다.

그리고 모든 것이 명확해집니다. 첫 번째 행은 무엇입니까? 702입니다. 원래 이 값을 설정한 트랜잭션 ID입니다. 나의 Granted 칼럼에는 무엇이 적혀 있나요? 나에겐 흔적이 있다 f. 트랜잭션 ID 5가 종료되기를 기다리고 있기 때문에 (6, 7, 702)이 승인될 수 없는 업데이트입니다. 거래 ID 차단이 있습니다. 이로 인해 5개의 트랜잭션 ID 잠금이 발생합니다.

그리고 704, 705를 보면 거기에는 아직 아무것도 쓰여 있지 않습니다. 왜냐하면 그들은 아직 무슨 일이 일어나고 있는지 모르기 때문입니다. 그들은 단지 무슨 일이 일어나고 있는지 전혀 모른다고 씁니다. 그리고 그들은 누군가가 끝내기를 기다리고 행을 바꿀 기회가 있을 때 깨어나기를 기다리기 때문에 그냥 잠에 들 것입니다.

이것이 어떻게 생겼는지입니다. 그들은 모두 12번째 줄을 기다리고 있는 것이 분명하다.

이것이 우리가 여기서 본 것입니다. 0/12입니다.

따라서 첫 번째 거래가 승인되면 여기에서 계층 구조가 어떻게 작동하는지 확인할 수 있습니다. 이제 모든 것이 명확해졌습니다. 모두 깨끗해집니다. 그리고 그들은 실제로 아직도 기다리고 있습니다.

현재 상황은 다음과 같습니다. 702 커밋. 이제 703은 이 행 잠금을 획득하고 704는 703이 커밋되기를 기다리기 시작합니다. 그리고 705도 이것을 기다리고 있습니다. 그리고 이 모든 것이 완료되면 그들은 스스로를 정리합니다. 그리고 저는 모두가 줄을 서고 있다는 점을 지적하고 싶습니다. 그리고 이것은 모두가 첫 번째 차를 기다리는 교통 체증 상황과 매우 유사합니다. 첫 번째 차가 멈추고 모두가 길게 줄을 섭니다. 그런 다음 이동하면 다음 차량이 앞으로 주행하여 블록을 얻을 수 있습니다.

이것이 충분히 복잡해 보이지 않는다면 이제 교착 상태에 대해 이야기하겠습니다. 나는 여러분 중 누가 그런 문제를 겪었는지 모릅니다. 이는 데이터베이스 시스템에서 매우 일반적인 문제입니다. 그러나 교착 상태는 한 세션이 다른 세션이 어떤 작업을 수행하기를 기다리는 경우입니다. 그리고 이 순간 또 다른 세션이 첫 번째 세션이 뭔가를 하기를 기다리고 있습니다.

예를 들어, Ivan이 "나에게 뭔가를 주세요"라고 말하면 나는 "아니요, 당신이 나에게 다른 것을 주어야만 그것을 줄 것입니다."라고 말합니다. 그리고 그는 “아니요, 당신이 나에게 주지 않으면 나는 그것을 당신에게 주지 않을 것입니다.”라고 말합니다. 그리고 결국 교착상태에 빠지게 됩니다. 나는 Ivan이 이것을 하지 않을 것이라고 확신합니다. 그러나 당신은 우리에게 무언가를 얻고 싶어하는 두 사람이 있고 다른 사람이 원하는 것을 줄 때까지 그것을 줄 준비가 되어 있지 않다는 의미를 이해합니다. 그리고 해결책이 없습니다.

그리고 본질적으로 데이터베이스는 이를 감지해야 합니다. 그런 다음 세션 중 하나를 삭제하거나 닫아야 합니다. 그렇지 않으면 해당 세션이 영원히 그대로 유지되기 때문입니다. 그리고 우리는 그것을 데이터베이스와 운영 체제에서 봅니다. 그리고 병렬 프로세스가 있는 모든 곳에서 이런 일이 발생할 수 있습니다.

이제 두 개의 교착 상태를 설치하겠습니다. 50과 80을 입력하겠습니다. 첫 번째 행에서는 50에서 50으로 업데이트하겠습니다. 거래 번호는 710입니다.

그런 다음 80을 81로, 50을 51로 변경하겠습니다.

그리고 이것이 모습이 될 것입니다. 따라서 710에는 행이 차단되었으며 711은 확인을 기다리고 있습니다. 우리는 업데이트할 때 이것을 보았습니다. 710은 우리 시리즈의 소유자입니다. 그리고 711은 710이 거래를 완료할 때까지 기다립니다.

그리고 어느 행에서 교착 상태가 발생했는지도 알려줍니다. 그리고 여기서 이상해지기 시작합니다.

이제 80을 80으로 업데이트하고 있습니다.

그리고 여기서 교착상태가 시작됩니다. 710은 711의 응답을 기다리고, 711은 710을 기다리고 있습니다. 그리고 이 일은 잘 끝나지 않을 것입니다. 그리고 여기서 벗어날 방법은 없습니다. 그리고 그들은 서로의 반응을 기대할 것입니다.

그리고 그것은 모든 것을 지연시키기 시작할 것입니다. 그리고 우리는 그것을 원하지 않습니다.

그리고 Postgres에는 이런 일이 발생했을 때 이를 알아차릴 수 있는 방법이 있습니다. 그리고 이런 일이 발생하면 이런 오류가 발생합니다. 그리고 이것으로부터 그러한 프로세스가 다른 프로세스, 즉 711 프로세스에 의해 차단된 SHARE LOCK을 기다리고 있다는 것이 분명합니다. 그리고 그 프로세스는 이러저러한 트랜잭션 ID에 대해 SHARE LOCK이 제공되기를 기다리고 있었고 이러저러한 프로세스에 의해 차단되었습니다. 따라서 여기에는 교착상태가 발생합니다.

XNUMX방향 교착상태가 있습니까? 가능합니까? 예.

이 숫자를 표에 입력합니다. 40을 40으로 변경하고 차단합니다.

60을 61로, 80을 81로 변경합니다.

그리고 80을 바꾸면 펑!

그리고 714는 이제 715를 기다리고 있습니다. 716은 715를 기다리고 있습니다. 그리고 그것에 대해 아무것도 할 수 없습니다.

여기에는 더 이상 두 사람이 없습니다. 여기에는 이미 세 사람이 있습니다. 나는 당신에게 무엇인가를 원하고, 이 사람은 제XNUMX자에게 무엇인가를 원하고, 제XNUMX자는 나에게 무엇인가를 원합니다. 그리고 우리는 모두 다른 사람이 해야 할 일을 완료하기를 기다리고 있기 때문에 결국 삼자 기다림에 빠지게 됩니다.

그리고 Postgres는 이것이 어느 행에서 발생하는지 알고 있습니다. 그러면 세 개의 입력이 서로를 차단하는 문제가 있음을 보여주는 다음 메시지가 표시됩니다. 그리고 여기에는 제한이 없습니다. 20개의 항목이 서로를 차단하는 경우가 있을 수 있습니다.

다음 문제는 직렬화 가능입니다.

특별한 직렬화 가능 잠금인 경우.

그리고 719로 돌아갑니다. 출력은 매우 정상입니다.

그리고 클릭하면 트랜잭션을 직렬화할 수 있습니다.

그리고 이제 다른 종류의 SA 잠금이 있다는 것을 알게 되었습니다. 이는 직렬화 가능을 의미합니다.

그래서 우리는 직렬 잠금 장치인 SARieadLock이라는 새로운 유형의 잠금 장치를 사용하여 일련 번호를 입력할 수 있습니다.

또한 고유 인덱스를 삽입할 수도 있습니다.

이 테이블에는 고유 인덱스가 있습니다.

그래서 여기에 숫자 2를 넣으면 2가 됩니다. 하지만 맨 위에는 또 다른 2를 넣었습니다. 그리고 721에는 전용 잠금 장치가 있는 것을 볼 수 있습니다. 그러나 이제 722는 721에 무슨 일이 일어날지 알 때까지 2를 삽입할 수 없기 때문에 721의 작업이 완료되기를 기다리고 있습니다.

그리고 우리가 하위 트랜잭션을 수행한다면.

여기에는 723이 있습니다.

그리고 포인트를 저장한 다음 업데이트하면 새로운 거래 ID를 얻게 됩니다. 이것은 당신이 알아야 할 또 다른 행동 패턴입니다. 이것을 반환하면 트랜잭션 ID가 사라집니다. 724개의 잎. 하지만 지금은 725개가 있습니다.

그럼 내가 여기서 뭘 하려는 거지? 나는 여러분이 발견할 수 있는 특이한 잠금의 예를 보여주려고 합니다. 직렬화 가능한 잠금이든 SAVEPOINT이든 잠금 테이블에 나타나는 다양한 유형의 잠금입니다.

이는 pg_advisory_lock이 있는 명시적(명시적) 잠금을 생성하는 것입니다.

그리고 차단 유형이 권고로 나열되어 있는 것을 볼 수 있습니다. 그리고 여기에 빨간색으로 "권고"라고 표시되어 있습니다. 그리고 pg_advisory_unlock을 사용하면 이와 같이 동시에 차단할 수도 있습니다.

그리고 결론적으로, 저는 여러분에게 놀라운 사실을 한 가지 더 보여드리고 싶습니다. 또 다른 뷰를 만들어 보겠습니다. 하지만 pg_locks 테이블을 pg_stat_activity 테이블과 결합하겠습니다. 그리고 나는 왜 이 일을 하고 싶은 걸까요? 이를 통해 모든 현재 세션을 살펴보고 그들이 기다리고 있는 잠금의 종류를 정확하게 확인할 수 있기 때문입니다. 그리고 이는 잠금 테이블과 쿼리 테이블을 함께 사용하면 매우 흥미롭습니다.

그리고 여기서 pg_stat_view를 만듭니다.

그리고 행을 하나씩 업데이트합니다. 여기에는 724가 표시됩니다. 그런 다음 행을 XNUMX으로 업데이트합니다. 그리고 지금 여기에서 무엇이 보이나요? 이는 요청입니다. 즉, 왼쪽 열에 나열된 전체 요청 목록이 표시됩니다. 그런 다음 오른쪽에서 막힌 부분과 이로 인해 생성되는 내용을 볼 수 있습니다. 그리고 매번 각 세션으로 돌아가 참여해야 하는지 여부를 확인할 필요가 없도록 더욱 명확해질 수 있습니다. 그들은 우리를 위해 그것을 합니다.

매우 유용한 또 다른 기능은 pg_blocking_pids. 당신은 아마 그녀에 대해 들어본 적이 없을 것입니다. 그녀가 무엇을하고 있니? 이를 통해 이 세션 11740에 대해 어떤 특정 프로세스 ID를 기다리고 있는지 알 수 있습니다. 그리고 11740이 724를 기다리고 있는 것을 볼 수 있습니다. 그리고 724가 맨 위에 있습니다. 11306은 프로세스 ID입니다. 기본적으로 이 기능은 잠금 테이블을 통과합니다. 그리고 그것이 조금 복잡하다는 것도 알지만, 여러분은 그것을 이해하게 되었습니다. 본질적으로 이 함수는 이 잠금 테이블을 살펴보고 이 프로세스 ID에 대기 중인 잠금이 부여된 위치를 찾으려고 시도합니다. 그리고 잠금을 기다리고 있는 프로세스의 프로세스 ID가 무엇인지 알아내려고 시도합니다. 따라서 이 기능을 실행할 수 있습니다. pg_blocking_pids.

그리고 이것은 매우 유용할 수 있습니다. 버전 9.6에서만 이 기능을 추가했기 때문에 이 기능은 나온 지 5년밖에 안 됐지만 매우 매우 유용합니다. 두 번째 요청에도 동일하게 적용됩니다. 우리가 봐야 할 것이 무엇인지 정확하게 보여줍니다.

이것이 제가 당신에게 이야기하고 싶었던 것입니다. 그리고 예상했던 대로 슬라이드가 너무 많아서 시간을 다 써버렸어요. 그리고 슬라이드를 다운로드할 수 있습니다. 이 자리에 있어주셔서 감사하다는 말씀을 전하고 싶습니다. 남은 컨퍼런스도 즐거우실 거라 확신합니다. 정말 감사합니다!

질문 :

예를 들어 행을 업데이트하려고 하는데 두 번째 세션에서 전체 테이블을 삭제하려고 하는 경우입니다. 내가 아는 한 의도 잠금과 같은 것이 있어야 합니다. Postgres에 그런 것이 있습니까?

처음으로 돌아가 보겠습니다. 예를 들어 SELECT를 수행하는 등의 작업을 수행하면 AccessShareLock이 발행된다는 것을 기억하실 것입니다. 그리고 이것은 테이블이 떨어지는 것을 방지합니다. 따라서 예를 들어 테이블의 행을 업데이트하거나 행을 삭제하려는 경우 전체 테이블과 행에 대해 이 AccessShareLock을 보유하고 있기 때문에 누군가 동시에 전체 테이블을 삭제할 수 없습니다. 완료되면 삭제할 수 있습니다. 하지만 거기에서 무언가를 직접 변경하는 동안에는 변경할 수 없습니다.

다시 해보자. 삭제 예시로 넘어가겠습니다. 그리고 전체 테이블 위의 행에 배타적 잠금이 어떻게 설정되어 있는지 확인할 수 있습니다.

이것은 잠금 전용처럼 보일 것입니다. 그렇죠?

네, 그럴 것 같습니다. 나는 당신이 말하는 것을 이해합니다. SELECT를 수행하고 ShareExclusive를 갖게 된 다음 이를 Row Exclusive로 설정하면 문제가 된다는 말씀이신가요? 그러나 놀랍게도 이는 문제를 일으키지 않습니다. 이는 잠금 수준을 높이는 것처럼 보이지만 본질적으로 삭제를 방지하는 잠금이 있습니다. 이제 이 잠금 장치를 더욱 강력하게 만들어도 여전히 삭제를 방지할 수 있습니다. 그래서 올라가는 건 아닌 것 같아요. 즉, 낮은 레벨일 때도 발생하지 않도록 방지했기 때문에 레벨을 올려도 테이블이 삭제되는 것을 방지합니다.

나는 당신이 말하는 것을 이해합니다. 여기에는 더 강력한 잠금을 도입하기 위해 하나의 잠금을 포기하려고 하는 잠금 에스컬레이션 사례가 없습니다. 여기서는 전반적으로 예방 기능을 강화하므로 충돌이 발생하지 않습니다. 하지만 좋은 질문입니다. 이렇게 물어봐주셔서 정말 감사합니다!

세션이 많고, 사용자 수가 많은 경우 교착상태를 피하기 위해서는 어떻게 해야 할까요?

Postgres는 교착 상태 상황을 자동으로 감지합니다. 그리고 세션 중 하나가 자동으로 삭제됩니다. 데드 블로킹을 방지하는 유일한 방법은 사람들을 같은 순서로 차단하는 것입니다. 따라서 응용 프로그램을 보면 종종 교착 상태의 원인이 표시됩니다. 두 가지 다른 항목을 차단하고 싶다고 상상해 봅시다. 한 응용 프로그램은 테이블 1을 잠그고 다른 응용 프로그램은 2를 잠근 다음 테이블 1을 잠급니다. 교착 상태를 피하는 가장 쉬운 방법은 응용 프로그램을 살펴보고 잠금이 모든 응용 프로그램에서 동일한 순서로 발생하는지 확인하는 것입니다. 그리고 모든 종류의 사람들이 이러한 애플리케이션을 작성하기 때문에 일반적으로 문제의 80%가 제거됩니다. 그리고 동일한 순서로 차단하면 교착 상태가 발생하지 않습니다.

귀하의 공연에 진심으로 감사드립니다! Vacuum Full에 대해 말씀하셨는데, 제가 올바르게 이해한다면 Vacuum Full은 별도의 저장소에 있는 레코드의 순서를 왜곡하므로 현재 레코드를 변경하지 않고 유지합니다. 진공 전체가 배타적 잠금 액세스를 취하는 이유는 무엇이며 쓰기 작업과 충돌하는 이유는 무엇입니까?

그건 좋은 질문이야. 그 이유는 진공이 가득 차서 테이블을 차지하기 때문입니다. 그리고 우리는 본질적으로 새로운 버전의 테이블을 생성하고 있습니다. 그리고 테이블은 새 것이 될 것입니다. 이것은 완전히 새로운 버전의 테이블이 될 것으로 밝혀졌습니다. 그리고 문제는 우리가 이 작업을 수행할 때 사람들이 새 테이블을 보기 위해 필요하기 때문에 그것을 읽는 것을 원하지 않는다는 것입니다. 그래서 이것은 이전 질문과 연결됩니다. 동시에 읽을 수 있다면 그것을 옮기거나 사람들을 새로운 테이블로 안내할 수 없을 것입니다. 모든 사람이 이 테이블을 다 읽을 때까지 기다려야 하므로 이는 본질적으로 잠금 배타적 상황입니다.
우리는 모든 사람을 새 복사본으로 이동하려면 마지막에 배타적 잠금이 필요하다는 것을 알고 있기 때문에 처음부터 잠근다고 말합니다. 따라서 우리는 이 문제를 잠재적으로 해결할 수 있습니다. 그리고 우리는 동시 인덱싱을 통해 이를 수행합니다. 그러나 이것은 하기가 훨씬 더 어렵습니다. 그리고 이것은 독점 잠금에 대한 이전 질문과 매우 관련이 있습니다.

Postgres에 잠금 시간 초과를 추가할 수 있습니까? 예를 들어 Oracle에서는 "업데이트 선택"이라고 쓰고 업데이트하기 전에 50초 동안 기다릴 수 있습니다. 적용하기에는 좋았습니다. 하지만 Postgres에서는 전혀 기다리지 않고 즉시 수행하거나 어느 정도 기다려야 합니다.

예, 잠금에 대한 시간 제한을 선택할 수 있습니다. 즉시 잠금을 얻을 수 없는 경우 no way 명령을 실행할 수도 있습니다. 따라서 잠금 시간 초과 또는 이를 수행할 수 있는 다른 기능이 필요합니다. 이는 구문 수준에서는 수행되지 않습니다. 이는 서버에서 변수로 수행됩니다. 때로는 이것을 사용할 수 없습니다.

슬라이드 75를 열 수 있나요?

네.

그리고 내 질문은 다음과 같습니다. 두 업데이트 프로세스 모두 703을 예상하는 이유는 무엇입니까?

그리고 이것은 좋은 질문입니다. 그런데 Postgres가 왜 이런 일을 하는지 이해가 되지 않습니다. 하지만 703이 만들어졌을 때는 702를 기대하고 있었습니다. 그리고 704와 705가 나타나면 아직 아무것도 없기 때문에 무엇을 기대하는지 모르는 것 같습니다. 그리고 Postgres는 이렇게 합니다. 잠금을 얻을 수 없으면 이미 누군가를 기다리고 있기 때문에 “What’s the point inprocess you?”라고 씁니다. 그래서 우리는 그것을 공중에 매달아 놓을 것입니다. 전혀 업데이트되지 않을 것입니다. 그런데 여기서 무슨 일이 일어났나요? 702가 프로세스를 완료하고 703이 잠금을 수신하자마자 시스템이 다시 돌아왔습니다. 그리고 그녀는 이제 우리를 기다리고 있는 사람이 두 명 있다고 말했습니다. 그런 다음 함께 업데이트해 보겠습니다. 그리고 둘 다 기대하고 있음을 나타냅니다.

Postgres가 왜 이런 일을 하는지 모르겠습니다. 그런데 f라는 문제가 있는데… 이것은 러시아어로 된 용어가 아닌 것 같습니다. 성을 기다리는 관원이 20명이더라도 모두가 하나의 성을 기다리는 때이다. 그리고 갑자기 그들은 모두 동시에 깨어납니다. 그리고 모두가 반응하려고 노력하기 시작합니다. 하지만 시스템에서는 모두가 703을 기다리게끔 만들어 놓았습니다. 왜냐하면 모두가 기다리고 있기 때문에 우리는 즉시 그들을 모두 정렬해 놓을 것입니다. 그리고 이후에 생성된 다른 새 요청(예: 707)이 나타나면 다시 비어 있게 됩니다.

그리고 이것은 현 단계에서 702가 703을 기다리고 있고 그 이후에 오는 모든 사람들은 이 분야에 진입할 수 없다고 말할 수 있도록 하기 위해 수행된 것 같습니다. 하지만 첫 번째 웨이터가 떠나자마자 업데이트 전 그 순간에 기다리고 있던 모든 사람들은 동일한 토큰을 받습니다. 그래서 순서대로 처리해서 제대로 주문할 수 있도록 이렇게 하는 것 같아요.

나는 항상 이것을 다소 이상한 현상으로 보았습니다. 예를 들어 여기서는 전혀 나열하지 않기 때문입니다. 하지만 우리가 새로운 자물쇠를 줄 때마다 우리는 기다리고 있는 사람들을 모두 쳐다보는 것 같습니다. 그런 다음 모두 정렬합니다. 그런 다음 들어오는 새로운 사람은 다음 사람이 처리를 마친 후에만 대기열에 들어갑니다. 아주 좋은 질문입니다. 귀하의 질문에 진심으로 감사드립니다!

705가 704를 기대하는 것이 훨씬 더 논리적인 것 같습니다.

그러나 여기서 문제는 다음과 같습니다. 기술적으로는 둘 중 하나를 깨울 수 있습니다. 그래서 우리는 둘 중 하나를 깨울 것입니다. 하지만 시스템에서는 무슨 일이 일어나는가? 맨 위에 있는 703이 자신의 거래 ID를 어떻게 차단했는지 확인할 수 있습니다. 이것이 Postgres의 작동 방식입니다. 그리고 703은 자체 트랜잭션 ID로 차단되므로 누군가 기다리기를 원한다면 703을 기다리게 됩니다. 그리고 본질적으로 703이 완료됩니다. 그리고 완료 후에야 프로세스 중 하나가 깨어납니다. 그리고 우리는 이 과정이 정확히 무엇인지 모릅니다. 그런 다음 모든 것을 점진적으로 처리합니다. 그러나 어떤 프로세스가 먼저 활성화되는지는 확실하지 않습니다. 왜냐하면 이러한 프로세스 중 하나일 수 있기 때문입니다. 본질적으로 우리는 이제 이러한 프로세스를 깨울 수 있다고 말하는 스케줄러를 가지고 있었습니다. 우리는 무작위로 하나를 선택합니다. 그러므로 둘 중 하나를 깨울 수 있기 때문에 둘 다 주목해야 합니다.

그리고 문제는 CP-무한대가 있다는 것입니다. 그러므로 우리가 나중에 깨어날 가능성이 높습니다. 예를 들어, 나중에 블록을 깨운 경우 방금 블록을 받은 사람을 기다리므로 정확히 누가 먼저 깨어날지 결정할 수 없습니다. 우리는 그러한 상황을 만들어내기만 하면 시스템이 무작위 순서로 그들을 깨울 것입니다.

이 Egor Rogov의 자물쇠에 관한 기사. 보세요, 그것들은 또한 흥미롭고 유용합니다. 물론 주제는 매우 복잡합니다. 정말 고마워요, 브루스!

출처 : habr.com