Postgresql 对象 ID 和元组
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3570387/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Postgresql object ID and tuples
提问by user431221
I sometimes see messages like
我有时会看到类似的消息
Process 12990 waits for ExclusiveLock on tuple (889,66) of relation 17720 of database 17607; blocked by process 12992.
进程 12990 在数据库 17607 的关系 17720 的元组 (889,66) 上等待 ExclusiveLock；被进程 12992 阻止。
So of course the 'process' part is quite clear, but I don't know how to correlate between the relation ID and a human readable name. I also don't really know what to make of the tuple bit.
所以当然“过程”部分很清楚，但我不知道如何关联关系 ID 和人类可读的名称。我也不知道如何处理元组位。
Anyone know how to read these messages and how to glean useful data from them?
有谁知道如何阅读这些消息以及如何从中收集有用的数据？
Thanks!
谢谢！
回答by whit537
A "relation" is a table and a "tuple" is a row.
“关系”是一张表，“元组”是一行。
Here's a nice shortcutfor getting the name of the table from the table id (you can also query the pg_classtable):
这是从表 id 中获取表名的一个不错的快捷方式（您也可以查询pg_class表）：
=> select 17720::regclass;
┌──────────┐
│ regclass │
├──────────┤
│ my_table │
└──────────┘
(1 row)
Now how about the row? The "tuple bit" is a tuple identifier, and every table in your database has a special system columncalled ctidwhere those identifiers are stored. Now that we know the table in question, we can do:
现在行呢？“元组位”是一个元组标识符，数据库中的每个表都有一个特殊的系统列，称为ctid存储这些标识符的位置。现在我们知道有问题的表格，我们可以这样做：
=> select * from my_table where ctid='(889,66)';
However! From the system column docs (emphasis added): "[A]lthough the ctid can be used to locate the row version very quickly, a row's ctid will changeif it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier." In other words, if you're quick enough you can probably trust that the row returned is the one involved in the deadlock, but that info won't be available forever.
然而！来自系统列文档（强调已添加）：“[A]虽然 ctid 可用于非常快速地定位行版本，但如果行的 ctid被 VACUUM FULL 更新或移动，则该行的 ctid 会发生变化。因此，ctid 是无用的-term 行标识符。” 换句话说，如果您足够快，您可能会相信返回的行是参与死锁的行，但该信息不会永远可用。
回答by Peter Tillemans
You can look this up the system tables : the one of interest here is pg_class.
您可以在系统表中查找：这里感兴趣的是pg_class.
Doing a query like
做一个像这样的查询
SELECT OID, relname FROM pg_class
oid | relname
-------+------------------------------------
1247 | pg_type
11550 | user_mapping_options
11554 | user_mappings
11494 | triggered_update_columns
11497 | triggers
or rather
更确切地说
SELECT relname FROM pg_class WHERE OID=17720
might shed light on the locks.
可能会照亮锁。
