Postgres ロック マネージャーのロックを解除します。 ブルース・モムジアン

Bruce Momjian の 2020 年の講演「Postgres ロック マネージャーのロック解除」の書き起こし。

(注: スライドのすべての SQL クエリは、次のリンクから入手できます。 http://momjian.us/main/writings/pgsql/locking.sql)

こんにちは！ 再びここロシアに来られて嬉しいです。 去年は来られなくて残念ですが、今年はイワンと私には大きな計画があります。 もっと頻繁にここに来たいと思っています。 ロシアに来るのが大好きです。 トヴェリのチュメニを訪問します。 これらの都市を訪れることができてとてもうれしいです。

私の名前はブルース・モムジアンです。 私は EnterpriseDB で働いており、23 年以上 Postgres を使ってきました。 私はアメリカのフィラデルフィアに住んでいます。 私は年間約90日旅行します。 そして私は約40のカンファレンスに参加しています。 私の いいえには、これからお見せするスライドが含まれています。 したがって、カンファレンス終了後、私の個人ウェブサイトからダウンロードできます。 約 30 件のプレゼンテーションも含まれています。 ビデオや 500 を超える多数のブログ エントリもあります。これはかなり有益なリソースです。 この資料にご興味がございましたら、ぜひご利用ください。

私は Postgres を使い始める前は教師、教授をしていました。 そして、これから私が伝えようとしていることを皆さんにお伝えできることをとても嬉しく思います。 これは私のプレゼンテーションの中で最も興味深いものの 110 つです。 このプレゼンテーションには XNUMX 枚のスライドが含まれています。 最初は簡単なことから話し始めますが、最後にはレポートはどんどん複雑になっていき、かなり複雑なものになっていきます。

これはかなり不愉快な会話です。 ブロッキングは最も人気のあるテーマではありません。 これはどこかに消えてほしい。 歯医者に行くようなものです。

1. データベースで作業し、複数のプロセスを同時に実行している多くの人にとって、ロックは問題です。 彼らにはブロックが必要だ。 ということで、今日はブロッキングの基礎知識をお伝えします。
2. トランザクション ID。 これはプレゼンテーションのかなり退屈な部分ですが、理解する必要があります。
3. 次に、ブロックの種類について説明します。 これはかなり機械的な部品です。
4. 以下に、ブロックの例をいくつか示します。 そしてそれを理解するのはかなり難しいでしょう。

ブロックについて話しましょう。

私たちの用語は非常に複雑です。 この一節の出典を知っている人は何人いますか? 二人。 これはColossal Cave Adventureというゲームからのものです。 80年代のテキストベースのコンピューターゲームだったと思います。 そこでは洞窟に入ったり、迷宮に入ったりする必要があり、テキストは変わりましたが、内容は毎回ほぼ同じでした。 そんな感じでこのゲームを思い出しました。

ここに、Oracle から提供されたロックの名前が表示されます。 私たちはそれらを使用しています。

ここで私を混乱させる用語が出てきます。 たとえば、SHARE UPDATE ECXLUSIVE などです。 次にRAW ECXLUSIVEを共有します。 正直に言うと、これらの名前はあまり明確ではありません。 それらをさらに詳しく検討していきます。 分離を意味する「share」という言葉が含まれているものもあります。 「独占」という言葉が含まれているものもあります。 これらの単語の両方を含むものもあります。 これらのロックがどのように機能するかから始めたいと思います。

そして「アクセス」という言葉も非常に重要です。 そして、「行」という単語は文字列です。 つまり、アクセス分散、行分散です。

Postgres で理解する必要があるもう XNUMX つの問題は、残念ながら私の講演では取り上げることができませんが、MVCC です。 このトピックに関する別のプレゼンテーションを私のウェブサイトに掲載しています。 このプレゼンテーションが難しいと思うなら、おそらく MVCC が私にとって最も難しいプレゼンテーションです。 ご興味がございましたら、ウェブサイトでご覧いただけます。 ビデオを見ることができます。

もう XNUMX つ理解する必要があるのは、トランザクション ID です。 多くのトランザクションは、一意の識別子がなければ機能しません。 ここで、トランザクションとは何かについて説明します。 Postgres には XNUMX つのトランザクション番号付けシステムがあります。 これがあまりきれいな解決策ではないことは承知しています。

また、スライドは非常にわかりにくいので、注意が必要な部分は赤でハイライトされています。

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

見てみましょう。 トランザクション番号は赤色で強調表示されます。 SELECT pg_back 関数をここに示します。 私のトランザクションとトランザクションIDが返されます。

もう XNUMX つ、このプレゼンテーションが気に入ってデータベース上で実行したい場合は、このピンク色のリンクに移動して、このプレゼンテーションの SQL をダウンロードできます。 PSQL で実行するだけで、プレゼンテーション全体がすぐに画面に表示されます。 花は含まれませんが、少なくともそれを見ることができます。

この場合、トランザクション ID が表示されます。 これは私たちが彼女に割り当てた番号です。 Postgres には仮想トランザクション ID と呼ばれる別のタイプのトランザクション ID があります。

そして私たちはこれを理解しなければなりません。 これは非常に重要です。そうしないと、Postgres でのロックを理解できなくなります。

仮想トランザクション ID は、永続的な値を含まないトランザクション ID です。 たとえば、SELECT コマンドを実行する場合、おそらくデータベースは変更されず、何もロックされません。 したがって、単純な SELECT を実行するときは、そのトランザクションに永続的な ID を与えません。 そこでは仮想 ID を彼女に与えるだけです。

これにより、Postgres のパフォーマンスが向上し、クリーンアップ機能が向上するため、仮想トランザクション ID は XNUMX つの数字で構成されます。 スラッシュの前の最初の数字はバックエンド ID です。 そして右側にはカウンターだけが見えます。

したがって、リクエストを実行すると、バックエンド ID は 2 であると表示されます。

このようなトランザクションを一連で実行すると、クエリを実行するたびにカウンターが増加することがわかります。 たとえば、クエリ 2/10、2/11、2/12 などを実行すると、

ここには 2 つの列があることに注意してください。 左側には、仮想トランザクション ID – 12/XNUMX が表示されます。 そして右側には永続的なトランザクション ID があります。 そしてこのフィールドは空です。 また、このトランザクションはデータベースを変更しません。 したがって、永続的なトランザクションIDは与えません。

分析コマンド ((ANALYZE)) を実行するとすぐに、同じクエリによって永続的なトランザクション ID が得られます。 これが私たちにとってどのように変わったかを見てください。 以前はこの ID を持っていませんでしたが、今は持っています。

そこで、別のリクエスト、別のトランザクションがあります。 仮想トランザクション番号は 2/13 です。 永続的なトランザクション ID を要求すると、クエリを実行するとそれが取得されます。

それでは、もう一度。 仮想トランザクション ID と永続トランザクション ID があります。 Postgres の動作を理解するには、この点を理解するだけです。

XNUMX 番目のセクションに進みます。 ここでは、Postgres のさまざまな種類のロックについて簡単に説明します。 あまり面白くないですね。 最後のセクションはさらに興味深いものになるでしょう。 しかし、基本的なことを考慮する必要があります。そうしないと、次に何が起こるかを理解できなくなります。

このセクションでは、各タイプのロックを見ていきます。 そして、それらがどのようにインストールされ、どのように機能するかの例を示し、Postgres でロックがどのように機能するかを確認するために使用できるいくつかのクエリを示します。

クエリを作成して Postgres で何が起こっているかを確認するには、システム ビューでクエリを発行する必要があります。 この場合、pg_lock が赤色で強調表示されます。 Pg_lock は、Postgres で現在どのようなロックが使用されているかを示すシステム テーブルです。

ただし、pg_lock は非常に複雑なので、それ自体を紹介するのは非常に困難です。 そこで、pg_locks を表示するビューを作成しました。 そして、それは私にとって、より深く理解することを可能にするいくつかの効果もあります。 つまり、私のロックや私自身のセッションなどは除外されます。これは単なる標準 SQL であり、何が起こっているかをより適切に示すことができます。

もう 2 つの問題は、このビューが非常に広いため、XNUMX 番目のビュー、lockviewXNUMX を作成する必要があることです。

そして、テーブルのさらに多くの列が表示されます。 もう XNUMX つは、残りの列を示しています。 これは非常に複雑なので、できるだけ簡単に説明しようとしました。

そこで、Lockdemo というテーブルを作成しました。 そしてそこに一本の線を作りました。 これはサンプルテーブルです。 また、ロックの例を示すためだけにセクションを作成します。

したがって、XNUMX 行、XNUMX 列になります。 最初のタイプのロックは ACCESS SHARE と呼ばれます。 これは最も制限の少ないブロックです。 これは、他のロックと実質的に競合しないことを意味します。

また、明示的にロックを定義したい場合は、「lock table」コマンドを実行します。 そしてそれは明らかにブロックします。つまり、ACCESS SHARE モードではロックテーブルを起動します。 また、PSQL をバックグラウンドで実行する場合は、この方法で最初のセッションから XNUMX 番目のセッションを開始します。 つまり、ここで何をしますか？ 別のセッションに移動して、「このリクエストのロックビューを表示してください」と指示します。 そして、このテーブルには AccessShareLock があります。 これはまさに私がリクエストしたものです。 そして、ブロックが割り当てられたと彼は言います。 とてもシンプルです。

さらに、XNUMX 番目の列を見ると、そこには何もありません。 それらは空です。

そして、「SELECT」コマンドを実行すると、これは AccessShareLock を要求する暗黙的 (明示的) 方法になります。 そこでテーブルを解放してクエリを実行すると、クエリは複数の行を返します。 そして、その行の XNUMX つに AccessShareLock が表示されます。 したがって、SELECT はテーブルに対して AccessShareLock を呼び出します。 また、これは低レベルのロックであるため、事実上何とも競合しません。

SELECT を実行し、XNUMX つの異なるテーブルがある場合はどうなりますか? 以前は XNUMX つのテーブルだけを実行していましたが、現在は pg_class、pg_namespace、pg_attribute の XNUMX つのテーブルを実行しています。

そしてクエリを見ると、9 つのテーブルに XNUMX つの AccessShareLock が表示されます。 なぜ？ pg_attribute、pg_class、pg_namespace の XNUMX つのテーブルが青で強調表示されます。 ただし、これらのテーブルを通じて定義されたすべてのインデックスにも 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 ブロックの XNUMX ページ目で、表内でブロックする内容が正確にわかります。 これはテーブルの個々の行をロックしますが、これは非常に興味深いものです。

これが私が伝えたかった基本情報のすべてです。 ロックについて、トランザクション ID について、仮想トランザクション ID について、永続的なトランザクション ID について説明しました。

次に、ブロックの例をいくつか見ていきます。 これが最も興味深い部分です。 非常に興味深い事例を見ていきます。 このプレゼンテーションの私の目標は、Postgres が特定のものをブロックしようとするときに実際に何をしているのかをよりよく理解していただくことです。 彼は部分を隠すのがとても上手だと思います。

いくつかの具体的な例を見てみましょう。

テーブルとテーブル内の XNUMX つの行から始めます。 何かを挿入すると、ExclusiveLock、Transaction ID、ExclusiveLock がテーブルに表示されます。

さらに XNUMX 行挿入するとどうなりますか? これで、テーブルには XNUMX 行が追加されました。 そして、XNUMX行を挿入し、これを出力として取得しました。 さらに XNUMX 行挿入すると、何がおかしなことになるでしょうか? このテーブルに XNUMX 行を追加したにもかかわらず、ロック テーブルにはまだ XNUMX 行が残っているため、ここで奇妙なことが起こります。 これは本質的に Postgres の基本的な動作です。

多くの人は、データベースで 100 行をロックする場合、100 個のロック エントリを作成する必要があると考えています。 一度に 1 行をブロックすると、そのようなクエリが 000 個必要になります。 そして、ブロックするのに1万または000億が必要な場合。 しかし、これをやってもうまくいきません。 個別の行ごとにブロッキング エントリを作成するシステムを使用したことがある場合、これが複雑であることがわかります。 オーバーフローする可能性があるロック テーブルをすぐに定義する必要がありますが、Postgres ではそれが行われないためです。

そして、このスライドで本当に重要なのは、MVCC 内で実行され、個々の行をロックする別のシステムが存在することを明確に示していることです。 したがって、数十億の行をロックする場合、Postgres は XNUMX 億の個別のロック コマンドを作成しません。 そして、これは生産性に非常に良い影響を与えます。

アップデートについてはどうですか？ 現在行を更新していますが、XNUMX つの異なる操作が同時に実行されていることがわかります。 同時にテーブルをロックしましたが、インデックスもロックしました。 このテーブルには一意の制約があるため、インデックスをロックする必要がありました。 そして、誰も変更しないようにしたいので、ブロックします。

XNUMX 行を更新したい場合はどうなりますか? そして彼も同じように行動していることがわかります。 更新回数は XNUMX 倍ですが、ロック行の数はまったく同じです。

Postgres がこれをどのように行うのか疑問に思っている場合は、MVCC に関する私の講演を聞いて、Postgres が変更するこれらの行を内部的にどのようにマークするかを学ぶ必要があります。 Postgres にはこれを行う方法がありますが、テーブル ロック レベルではなく、より低い効率的なレベルで行われます。

何かを削除したい場合はどうすればよいですか? たとえば、XNUMX 行を削除しても XNUMX つのブロック入力がまだ残っており、それらをすべて削除したいと思っても、それらはまだそこにあります。

たとえば、1 行を挿入し、その後 000 行を削除または追加し、追加または変更した個々の行はここには記録されません。 それらはシリーズ自体の下位レベルで書かれています。 そしてMVCCのスピーチの中で私はこれについて詳しく話しました。 ただし、ロックを分析するときは、テーブル レベルでロックしていることと、個々の行がここでどのように記録されているかを確認していないことを確認することが非常に重要です。

明示的なブロックについてはどうですか?

「更新」をクリックすると、XNUMX 行がロックされます。 そして、それらをすべて選択して「どこでも更新」をクリックしても、ブロックしているレコードが XNUMX つ残っています。

個々の行ごとに個別のレコードは作成しません。 そうなると生産性が落ちるので、多すぎる可能性があります。 そして、私たちは不快な状況に陥るかもしれません。

同じことを、共有する場合は、30 回すべて行うことができます。

テーブルを復元し、すべてを削除してから、もう一度 XNUMX 行を挿入します。

Postgres でよく知られており、望ましい動作であるもう XNUMX つの動作は、更新または選択を実行できることです。 そして、これを同時に行うこともできます。 また、選択は更新と逆方向の同じことをブロックしません。 私たちは読者にライターをブロックしないように言いますが、ライターはリーダーをブロックしませんでした。

この例を示します。 今から選択します。 次に INSERT を実行します。 そして、-694 が表示されます。この挿入を実行したトランザクションの ID が表示されます。 それが仕組みです。

そして今バックエンド ID を見ると、695 になっています。

そして、テーブルに 695 が表示されていることがわかります。

そして、ここをこのように更新すると、別のケースが表示されます。 この場合、695 は排他ロックであり、更新も同じ動作をしますが、それらの間に競合はありません。これは非常に珍しいことです。

そして、一番上が ShareLock、一番下が ExclusiveLock であることがわかります。 そして両方の取引はうまくいきました。

これがどのようにして起こるのかを理解するには、MVCC での私の講演を聞く必要があります。 ただし、これは同時に実行できる、つまり SELECT と UPDATE を同時に実行できることを示す例です。

リセットしてもう一度操作してみましょう。

同じ行で XNUMX つの更新を同時に実行しようとすると、ブロックされます。 リーダーはライターをブロックせず、ライターもリーダーをブロックしないが、あるライターが別のライターをブロックすると述べたことを思い出してください。 つまり、XNUMX 人が同じ行を同時に更新することはできません。 いずれかが終了するまで待つ必要があります。

これを説明するために、Lockdemo テーブルを見てみましょう。 そして 698 つの行を見てみましょう。 トランザクションごとに XNUMX。

これを2に更新しました。 699が最初のアップデートです。 そして、それは成功したか、保留中のトランザクションになっていて、私たちが確認するかキャンセルするのを待っています。

しかし、別のことに注目してください。2/51 は私たちの最初のトランザクション、最初のセッションです。 3/112 は、その値を 3 に変更した、先頭からの 699 番目のリクエストです。そして、気が付けば、先頭のリクエストはそれ自体 (3) をロックしました。しかし、112/699 はロックを許可しませんでした。 Lock_mode 列には、何を待っているかが示されます。 699 を期待しています。そして、XNUMX がどこにあるかを見ると、それはさらに高くなります。 そして、最初のセッションでは何をしましたか? 彼女は自分のトランザクション ID に排他的ロックを作成しました。 これがPostgresのやり方です。 自身のトランザクション ID をブロックします。 また、誰かが確認またはキャンセルするのを待ちたい場合は、保留中のトランザクションがある間待つ必要があります。 だからこそ、奇妙な線が見えるのです。

もう一度見てみましょう。 左側に処理 ID が表示されます。 699 番目の列には仮想トランザクション ID が表示され、XNUMX 番目の列には lock_type が表示されます。 これはどういう意味ですか？ 本質的には、トランザクション ID をブロックしているということです。 ただし、一番下の行はすべて関係を示していることに注意してください。 したがって、テーブルには XNUMX 種類のロックがあります。 リレーションロックがあります。 次に、transactionid のブロックがあります。ここでは、自分でブロックします。これは、最初の行または一番下で、transactionid が存在する場所で、XNUMX が操作を完了するのを待つ部分でまさに行われることです。

ここで何が起こるか見てみましょう。 そしてここでは XNUMX つのことが同時に起こります。 最初の行には、それ自体をロックするトランザクション ID ロックが表示されています。 そして、彼女は人々を待たせるために自分自身をブロックします。

6行目を見ると、699行目と同じエントリです。 したがって、トランザクション 700 はブロックされます。 699もセルフロック式です。 そして、一番下の行では、XNUMX が操作を完了するのを待っていることがわかります。

そして、lock_type のタプルには数字が表示されます。

0/10であることがわかります。 これはページ番号であり、この特定の行のオフセットでもあります。

そして、更新すると 0/11 になることがわかります。

ただし、この操作には待ち時間があるため、実際には 0/10 になります。 これが私が確認するのを待っているシリーズであることを確認する機会があります。

確認してコミットを押し、更新が完了すると、再びこのような結果が得られます。 トランザクション 700 が唯一のロックであり、コミットされているため、他のロックを待ちません。 トランザクションが完了するのを待つだけです。 699 がなくなると、もう何も待つ必要はありません。 そしてトランザクション 700 は、すべてが正常であり、許可されているすべてのテーブルに必要なすべてのロックがあることを示します。

そして、この全体をさらに複雑にするために、今度は階層を提供する別のビューを作成します。 あなたがこの要求を理解してくれるとは期待していません。 しかし、これにより、何が起こっているかをより明確に把握できるようになります。

これは再帰的なビューであり、別のセクションもあります。 そして、すべてが再びひとつに戻ります。 これを使ってみましょう。

3 つの同時更新を行って、行が 4 になった場合はどうなるでしょうか。 そして、XNUMXをXNUMXに変更します。

ここでは 4 が表示されます。トランザクション ID は 702 です。

それから 4 を 5 に変更します。そして 5 を 6 に、6 を 7 に変更します。そして、この XNUMX つの取引が終了するのを待っている何人かの人々を並べます。

そしてすべてが明らかになる。 最初の行は何ですか？ これは 702 です。これは、最初にこの値を設定したトランザクション ID です。 付与欄には何が書かれていますか？ 跡がついてるよ f。 これらは、トランザクション ID 5 が終了するのを待っているため、(6、7、702) を承認できない更新です。 そこにはトランザクション ID のブロックがあります。 これにより、5 つのトランザクション ID ロックが発生します。

そして、704 と 705 を見ると、まだ何が起こっているのかわからないため、そこにはまだ何も書かれていません。 彼らはただ何が起こっているのか分からないとだけ書いています。 そして、誰かが終わるのを待っているので、ただ寝てしまい、列を変える機会があれば起こされます。

見た目はこんな感じです。 彼ら全員が12行目を待っていることは明らかです。

これが私たちがここで見たものです。 こちらは0/12です。

最初のトランザクションが承認されると、ここで階層がどのように機能するかを確認できます。 そして今、すべてが明らかになります。 それらはすべてき​​れいになります。 そして彼らは実際にまだ待っています。

ここで何が起こっているのかを説明します。 702 コミット。 そして、703 がこの行ロックを取得し、704 は 703 がコミットするのを待ち始めます。 そして705もこれを待っています。 そして、これらすべてが完了すると、彼らは自分自身をきれいにします。 そして、皆さんが並んでいることを指摘したいと思います。 これは、渋滞で誰もが最初の車を待っている状況と非常によく似ています。 先頭の車両が止まり、全員が長蛇の列に並びます。 その後、車が動き、次の車が前進してブロックを取得することができます。

これが十分に複雑ではないと思われる場合は、次にデッドロックについて説明します。 皆さんのうち誰が彼らに遭遇したのか分かりません。 これはデータベース システムではよくある問題です。 しかし、デッドロックとは、あるセッションが別のセッションが何かを行うのを待っているときのことです。 そしてこの時点では、別のセッションが最初のセッションが何かを行うのを待っています。

そして、たとえば、イワンが「何かちょうだい」と言うと、私は「いいえ、あなたが何か他のものをくれる場合にのみ、あなたにあげます。」と言いました。 すると彼は、「いいえ、あなたがくれなければ、あげません」と言いました。 そして行き詰まりの状況に陥ってしまいます。 イワンはそんなことはしないと思いますが、何かを手に入れたいと思っている二人の人がいて、相手が欲しいものをくれるまではそれを渡す準備ができていないという意味は理解していただけたでしょうか。 そして解決策はありません。

そして基本的に、データベースはこれを検出する必要があります。 そして、セッションの XNUMX つを削除するか閉じる必要があります。そうしないと、セッションが永久に残ってしまいます。 そしてそれはデータベースやオペレーティング システムにも見られます。 そして、並列プロセスがあるすべての場所で、これが発生する可能性があります。

次に、50 つのデッドロックをインストールします。 80 と 50 を入力します。最初の行では、50 から 710 に更新します。トランザクション番号 XNUMX を取得します。

そして、80を81に、50を51に変更します。

そして、それは次のようになります。 したがって、710 にはブロックされた行があり、711 は確認を待っています。 更新したときにこれが見られました。 710 は私たちのシリーズのオーナーです。 そして、711 は 710 がトランザクションを完了するのを待ちます。

さらに、どの行でデッドロックが発生したかも表示されます。 そしてここからが奇妙になり始めます。

現在、80から80まで更新中です。

そしてここから行き詰まりが始まります。 710 は 711 からの応答を待ち、711 は 710 を待ちます。そして、これはうまく終わりません。 そして、これから抜け出す方法はありません。 そして、彼らはお互いからの反応を期待するでしょう。

そしてそれはすべてを遅らせ始めるだけです。 そして私たちはそれを望んでいません。

Postgres には、これが発生したときにそれを認識する方法があります。 これが起こると、このエラーが発生します。 このことから、これこれのプロセスが別のプロセスからの SHARE LOCK を待っている、つまり 711 プロセスによってブロックされていることが明らかです。 そして、そのプロセスは、これこれのトランザクション ID に対して SHARE LOCK が与えられるのを待っていましたが、そのプロセスによってブロックされました。 したがって、ここで行き詰まりの状況が発生します。

三方向のデッドロックはありますか? 出来ますか？ はい。

これらの数値をテーブルに入力します。 40を40に変更し、ブロックします。

60を61に、80を81に変更します。

そして80を変えてドーン！

そして、714番は現在715番を待っています。716番は715番を待っています。 そしてそれについては何もできません。

ここにはもう二人ではなく、すでに三人がいます。 私はあなたから何かが欲しい、この人は第三者から何かを望んでいる、そして第三者は私から何かを望んでいます。 そして、私たちは皆、相手がやるべきことを完了するのを待っているため、結局は三方待ち状態になってしまいます。

そして、Postgres はこれがどの行で発生するかを知っています。 そして、次のようなメッセージが表示されます。これは、20 つの入力が互いにブロックしているという問題があることを示しています。 そして、ここには制限はありません。 これは、XNUMX 個のエントリが互いにブロックしている場合に発生する可能性があります。

次の問題はシリアル化可能です。

特別なシリアル化可能なロックの場合。

そして、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 が表示されます。そして、行を XNUMX に更新します。 そして今ここで何が見えますか？ これらはリクエストです。つまり、左側の列にリストされているリクエストのリスト全体が表示されます。 そして右側には、詰まりとそれが生み出すものを見ることができます。 また、毎回各セッションに戻って参加する必要があるかどうかを確認する必要がなくなるため、より明確になります。 彼らは私たちのためにやってくれます。

非常に便利なもう XNUMX つの機能は、 pg_blocking_pids。 おそらく彼女のことを聞いたことがないでしょう。 彼女は何をやっている？ これにより、このセッション 11740 でどのような特定のプロセス ID を待っているかを知ることができます。 そして、11740 が 724 を待っていることがわかります。そして 724 が一番上にあります。 11306 はプロセス ID です。 基本的に、この関数はロック テーブルを通過します。 少し複雑だとは思いますが、なんとか理解していただけたでしょうか。 基本的に、この関数はこのロック テーブルを調べて、このプロセス ID に待機中のロックが与えられている場所を見つけようとします。 また、ロックを待っているプロセスがどのプロセス ID を持っているかを把握しようとします。 したがって、この関数を実行できます pg_blocking_pids.

そして、これは非常に便利です。 これはバージョン 9.6 で追加されたばかりなので、まだ 5 年しか経っていませんが、非常に便利です。 XNUMX 番目のリクエストにも同じことが当てはまります。 それはまさに私たちが見るべきものを示しています。

これが私があなたに話したかったことです。 そして予想通り、スライドが多かったので時間を使い果たしました。 スライドはダウンロード可能です。 ここに来ていただきありがとうございます。 残りのカンファレンスもお楽しみいただけると思います。ありがとうございました。

質問：

たとえば、行を更新しようとしていて、XNUMX 番目のセッションでテーブル全体を削除しようとしているとします。 私が理解している限り、インテントロックのようなものが存在するはずです。 Postgresにはそのようなものはありますか？

一番最初に戻ってみましょう。 何かを行うとき、たとえば SELECT を実行するとき、AccessShareLock が発行されることを覚えているかもしれません。 これにより、テーブルの落下を防ぐことができます。 したがって、たとえば、テーブル内の行を更新したり、行を削除したりする場合、この AccessShareLock をテーブル全体と行に対して保持しているため、誰かが同時にテーブル全体を削除することはできません。 そして、完了したら削除できます。 しかし、あなたがそこで何かを直接変更しても、彼らはそれを行うことができません。

もう一度やりましょう。 削除の例に移りましょう。 そして、テーブル全体の上の行に排他ロックがかかっていることがわかります。

これだとロック排他的に見えますよね？

はい、そのようです。 あなたが話していることは理解できます。 SELECT を実行すると ShareExclusive があり、それを Row Exclusive にすると言うのですが、それは問題になりますか? しかし、驚くべきことにこれは問題になりません。 これはロックの度合いを上げているように見えますが、本質的には削除を防ぐロックを持っています。 そして今、このロックをより強力にしても、削除は依然として防止されます。 だから上がるわけではないんです。 つまり、レベルが低いときもこの問題が発生するのを防ぐことができたので、レベルを上げてもテーブルが削除されるのを防ぐことができます。

あなたが話していることは理解できます。 ここには、より強力なロックを導入するために XNUMX つのロックを放棄しようとするロック エスカレーションのケースはありません。 ここでは、この防止を全体的に強化するだけなので、競合は発生しません。 しかし、それは良い質問です。 ご質問いただきまして誠にありがとうございます！

多数のセッションや多数のユーザーがある場合にデッドロック状況を回避するにはどうすればよいでしょうか?

Postgres はデッドロック状況を自動的に認識します。 また、セッションの 1 つが自動的に削除されます。 デッドブロッキングを回避する唯一の方法は、同じ順序で人々をブロックすることです。 したがって、アプリケーションを見ると、多くの場合、デッドロックの原因がわかります... 2 つの異なるものをブロックしたいと想像してみましょう。 1 つのアプリケーションがテーブル 80 をロックし、別のアプリケーションがテーブル XNUMX をロックし、次にテーブル XNUMX をロックします。デッドロックを回避する最も簡単な方法は、アプリケーションを調べて、すべてのアプリケーションでロックが同じ順序で発生することを確認することです。 これらのアプリケーションはさまざまな人々が作成するため、これにより通常、問題の XNUMX% が解消されます。 同じ順序でブロックすれば、デッドロック状況は発生しません。

ご出演誠にありがとうございました！ バキュームフルについて話しましたが、私の理解が正しければ、バキュームフルは別のストレージ内のレコードの順序を歪めるため、現在のレコードは変更されずに維持されます。 バキュームフルが排他的ロックアクセスを必要とするのはなぜですか?また、書き込み操作と競合するのはなぜですか?

それは良い質問です。 その理由は、真空がいっぱいになるとテーブルが占領されてしまうためです。 そして、基本的にテーブルの新しいバージョンを作成しています。 そしてテーブルも新しくなります。 これはテーブルの完全に新しいバージョンになることがわかりました。 そして問題は、これを行うとき、新しいテーブルを見てもらう必要があるため、人々にそれを読んでほしくないということです。 そして、これは前の質問につながります。 同時に読むことができたとしても、テーブルを移動して人々を新しいテーブルに誘導することはできません。 全員がこのテーブルの読み取りを完了するまで待つ必要があるため、本質的にはロック排他的な状況になります。
最初からロックすると言うのは、最後に全員を新しいコピーに移動するために排他的ロックが必要になることがわかっているからです。 したがって、これを解決できる可能性があります。 そして、この方法で同時インデックス作成を行います。 しかし、これを行うのははるかに困難です。 そして、これは排他的ロックに関する前の質問に非常に関連しています。

Postgresにロックタイムアウトを追加することはできますか? たとえば、Oracle では、「更新を選択」と記述し、更新する前に 50 秒待つことができます。 応用としては良かったです。 しかし、Postgres では、まったく待たずにすぐに実行するか、しばらく待つ必要があります。

はい、ロックごとにタイムアウトを選択できます。 no way コマンドを発行することもできます。すぐにロックを取得できない場合は、次のようになります。 したがって、ロック タイムアウトか、これを可能にする他の手段のいずれかが必要です。 これは構文レベルでは行われません。 これはサーバー上の変数として行われます。 これが使えない場合もあります。

スライド 75 を開いていただけますか?

はい。

そして私の質問は次のとおりです。 両方の更新プロセスが 703 を期待しているのはなぜですか?

そして、これは素晴らしい質問です。 ちなみに、Postgres がなぜこのようなことをするのかはわかりません。 しかし、703 が作成されたとき、702 が期待されていました。そして 704 と 705 が現れたとき、そこにはまだ何もないため、何を期待しているのかわからないようです。 そして、Postgres はこの方法でそれを行います。ロックを取得できない場合、「あなたを処理することに何の意味があるの?」と書きます。なぜなら、あなたはすでに誰かを待っているからです。 したがって、このまま放置しておくと、まったく更新されません。 しかし、ここで何が起こったのでしょうか？ 702 がプロセスを完了し、703 がロックを受け取るとすぐに、システムは戻りました。 そして彼女は、今二人が待っていると言いました。 そして、一緒に更新しましょう。 そして、両方が期待していることを示しましょう。

Postgres がなぜこれを行うのかはわかりません。 しかし、f…という問題があります。 これはロシア語ではないようです。 これは、城を待っている当局が 20 人いたとしても、全員が 703 つの城を待っている場合です。 そして突然全員が同時に目覚めます。 そして誰もが反応しようとし始めます。 しかし、システムでは、全員が 707 を待っているように設定されています。なぜなら、全員が待っているからです。すぐに全員を並べます。 この後に生成された他の新しいリクエスト (たとえば XNUMX) が表示されると、再び空になります。

そして、これは、この段階では 702 が 703 を待っており、その後に来る人はすべてこのフィールドにエントリーできないと言えるようにするために行われているように思えます。 ただし、最初のウェイターが去るとすぐに、更新前にその時点で待っていたすべての人が同じトークンを受け取ります。 それで、それがきちんと順番に処理できるようにするためにこうなっているのだと思います。

私はいつもこれをかなり奇妙な現象だと考えていました。 たとえば、ここではそれらをまったくリストしていないからです。 しかし、私たちが新しい鍵を与えるたびに、待っているすべての人に目を向けているように思えます。 次に、それらをすべて並べます。 そして、新しく入ってくる人は、次の人が処理を終えたときにのみキューに入れられます。 とても良い質問です。 ご質問いただきまして誠にありがとうございます！

705 が 704 を期待する方がはるかに論理的であるように私には思えます。

しかし、ここでの問題は次の点です。 技術的には、どちらか一方を起動することができます。 そして、私たちはどちらか一方を目覚めさせるでしょう。 しかし、システム内では何が起こっているのでしょうか? 一番上の 703 が自分のトランザクション ID をブロックしていることがわかります。 これが Postgres の仕組みです。 また、703 は独自のトランザクション ID によってブロックされているため、誰かが待ちたい場合は 703 を待つことになります。そして、本質的に 703 は完了します。 そして、その完了後にのみ、プロセスの XNUMX つが目覚めます。 そして、このプロセスが具体的にどのようなものになるのかはわかりません。 その後、すべてを徐々に処理していきます。 ただし、これらのプロセスのいずれかである可能性があるため、どのプロセスが最初に起動されるかは明らかではありません。 基本的に、これらのプロセスのいずれかを起動できるようにするスケジューラーがありました。 ランダムに XNUMX つを選択するだけです。 したがって、どちらかを目覚めさせることができるため、両方に注目する必要があります。

そして問題は、CP-infinityがあることです。 したがって、遅い方を目覚めさせることができる可能性が非常に高いです。 そして、たとえば、後の人を目覚めさせる場合、ブロックを受け取ったばかりの人を待つことになるため、正確に誰が最初に目覚めるかは決定しません。 私たちがそのような状況を作り出すだけで、システムはランダムな順序で彼らを目覚めさせます。

あり Egor Rogov によるロックに関する記事。 ほら、それらも興味深くて便利です。 もちろん、このテーマは非常に複雑です。 どうもありがとう、ブルース！

出所： habr.com