回答編集履歴
2
微修正
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
微修正
answer
CHANGED
@@ -28,8 +28,10 @@
|
|
28
28
|
|
29
29
|
> **指定されたプロセスにより保持されているロックを表す行内ではgrantedは真です。偽の場合はこのロックを獲得するため現在プロセスが待機中であることを示しています。つまり、同じロック対象のオブジェクトに対して何らかの他のプロセスが競合するロックを保持、もしくは待機していることを意味します。** 待機中のプロセスはその別のプロセスがロックを解放するまで活動を控えます。 (もしくはデッドロック状態が検出されることになります)。 単一プロセスでは一度に多くても1つのロックを獲得するために待機します。
|
30
30
|
|
31
|
-
|
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
|
```
|