teratail header banner
teratail header banner
質問するログイン新規登録

回答編集履歴

2

微修正

2019/08/03 02:10

投稿

退会済みユーザー
answer CHANGED
@@ -34,8 +34,8 @@
34
34
 
35
35
  - TX Aにてdelete実行直後のロック状態
36
36
 
37
- ```
37
+ ```psql
38
- SELECT l.pid,d.datname,l.locktype,relation::regclass,transactionid,l.mode,l.granted
38
+ > SELECT l.pid,d.datname,l.locktype,relation::regclass,transactionid,l.mode,l.granted
39
39
  FROM pg_locks l LEFT JOIN pg_database d ON l.database = d.oid
40
40
  WHERE l.pid != pg_backend_pid()
41
41
  ORDER BY l.pid;
@@ -53,8 +53,8 @@
53
53
  => TX A(id:1699)の完了を待っていることが、ShareLockがnot grantedであることからわかる
54
54
  > 119 | | transactionid | | 1699 | ShareLock | f
55
55
 
56
- ```
56
+ ```psql
57
- SELECT l.pid,d.datname,l.locktype,relation::regclass,transactionid,l.mode,l.granted
57
+ > SELECT l.pid,d.datname,l.locktype,relation::regclass,transactionid,l.mode,l.granted
58
58
  FROM pg_locks l LEFT JOIN pg_database d ON l.database = d.oid
59
59
  WHERE l.pid != pg_backend_pid()
60
60
  ORDER BY l.pid;
@@ -77,8 +77,8 @@
77
77
 
78
78
  - TX Aをcommitした直後のロック状態
79
79
 
80
- ```
80
+ ```psql
81
- SELECT l.pid,d.datname,l.locktype,relation::regclass,transactionid,l.mode,l.granted
81
+ > SELECT l.pid,d.datname,l.locktype,relation::regclass,transactionid,l.mode,l.granted
82
82
  FROM pg_locks l LEFT JOIN pg_database d ON l.database = d.oid
83
83
  WHERE l.pid != pg_backend_pid()
84
84
  ORDER BY l.pid;
@@ -91,7 +91,7 @@
91
91
  ```
92
92
 
93
93
  hoge_pkey は index
94
- ```
94
+ ```psql
95
- select * from hoge_pkey;
95
+ > select * from hoge_pkey;
96
96
  ERROR: "hoge_pkey" is an index
97
97
  ```

1

微修正

2019/08/03 02:10

投稿

退会済みユーザー
answer CHANGED
@@ -28,8 +28,10 @@
28
28
 
29
29
  > **指定されたプロセスにより保持されているロックを表す行内ではgrantedは真です。偽の場合はこのロックを獲得するため現在プロセスが待機中であることを示しています。つまり、同じロック対象のオブジェクトに対して何らかの他のプロセスが競合するロックを保持、もしくは待機していることを意味します。** 待機中のプロセスはその別のプロセスがロックを解放するまで活動を控えます。 (もしくはデッドロック状態が検出されることになります)。 単一プロセスでは一度に多くても1つのロックを獲得するために待機します。
30
30
 
31
- > トランザクションの実行中は常に、サーバプロセスはその仮想トランザクションID上に排他的ロックをかけます。 もしある永続IDがトランザクションに割り当てられる普通はトランザクションがデータベースの状態を変化させるときのみに発生しますと、トランザクションは終了するまで永続トランザクションIDに対して排他ロックを保持します。 **あるトランザクションが他のトランザクションを特定して終了まで待機しなければならないと判断した場合、他とみなしたトランザクションのIDに対し共有ロックを獲得するように試み、目的を達します。 (仮想IDであるか永続IDであるかは、その状況によります)。 これは、他とみなしたトランザクションが完了し、そしてロックを解放した場合のみ成功します。**
31
+ [pg_locks原文](https://www.postgresql.org/docs/9.6/view-pg-locks.html)
32
32
 
33
+ > Throughout running a transaction, a server process holds an exclusive lock on the transaction's virtual transaction ID. If a permanent ID is assigned to the transaction (which normally happens only if the transaction changes the state of the database), it also holds an exclusive lock on the transaction's permanent transaction ID until it ends. **When a process finds it necessary to wait specifically for another transaction to end, it does so by attempting to acquire share lock on the other transaction's ID (either virtual or permanent ID depending on the situation). That will succeed only when the other transaction terminates and releases its locks.**
34
+
33
35
  - TX Aにてdelete実行直後のロック状態
34
36
 
35
37
  ```