F.37. pg_walinspect — 低级别 WAL 检查#
pg_walinspect
模块提供 SQL 函数,允许您在低级别检查正在运行的PostgreSQL数据库集群的预写日志的内容,这对于调试、分析、报告或教育目的非常有用。它类似于pg_waldump,但可以通过 SQL 访问,而不是通过单独的实用程序。
此模块的所有函数都将使用服务器当前的时间线 ID 提供 WAL 信息。
注意
pg_walinspect
函数通常使用 LSN 参数调用,该参数指定感兴趣的已知 WAL 记录开始的位置。但是,某些函数(例如[pg_logical_emit_message](functions-admin.html#PG-LOGICAL-EMIT-MESSAGE)
)返回 LSN在刚刚插入的记录之后。
提示
所有pg_walinspect
函数都显示有关属于特定 LSN 范围的记录的信息,它们允许接受*end_lsn
参数,该参数位于服务器当前 LSN 之后。使用end_lsn
“来自未来”不会引发错误。将值FFFFFFFF/FFFFFFFF
(最大有效pg_lsn
值)作为end_lsn
参数可能很方便。这等效于提供与服务器当前 LSN 匹配的end_lsn
*参数。
默认情况下,仅限超级用户和pg_read_server_files
角色的成员使用这些函数。超级用户可以使用GRANT
向其他人授予访问权限。
F.37.1. 一般函数#
pg_get_wal_record_info(in_lsn pg_lsn) returns record
#获取位于
in_lsn
参数所在位置或之后位置的 WAL 记录信息。例如postgres=# SELECT * FROM pg_get_wal_record_info('0/E419E28'); -[ RECORD 1 ]----+------------------------------------------------- start_lsn | 0/E419E28 end_lsn | 0/E419E68 prev_lsn | 0/E419D78 xid | 0 resource_manager | Heap2 record_type | VACUUM record_length | 58 main_data_length | 2 fpi_length | 0 description | nunused: 5, unused: [1, 2, 3, 4, 5] block_ref | blkref #0: rel 1663/16385/1249 fork main blk 364
如果
in_lsn
不在 WAL 记录的开头,则会显示有关下一个有效 WAL 记录的信息。如果没有下一个有效 WAL 记录,则该函数会引发错误。pg_get_wal_records_info(start_lsn pg_lsn, end_lsn pg_lsn) returns setof record
#获取
start_lsn
和end_lsn
之间所有有效 WAL 记录的信息。为每个 WAL 记录返回一行。例如postgres=# SELECT * FROM pg_get_wal_records_info('0/1E913618', '0/1E913740') LIMIT 1; -[ RECORD 1 ]----+-------------------------------------------------------------- start_lsn | 0/1E913618 end_lsn | 0/1E913650 prev_lsn | 0/1E9135A0 xid | 0 resource_manager | Standby record_type | RUNNING_XACTS record_length | 50 main_data_length | 24 fpi_length | 0 description | nextXid 33775 latestCompletedXid 33774 oldestRunningXid 33775 block_ref |
如果
start_lsn
不可获取,则该函数会引发错误。pg_get_wal_block_info(start_lsn pg_lsn, end_lsn pg_lsn, show_data boolean DEFAULT true) returns setof record
#获取
start_lsn
和end_lsn
之间所有有效 WAL 记录中每个块引用的信息,这些记录包含一个或多个块引用。为每个 WAL 记录的每个块引用返回一行。例如postgres=# SELECT * FROM pg_get_wal_block_info('0/1230278', '0/12302B8'); -[ RECORD 1 ]-----+----------------------------------- start_lsn | 0/1230278 end_lsn | 0/12302B8 prev_lsn | 0/122FD40 block_id | 0 reltablespace | 1663 reldatabase | 1 relfilenode | 2658 relforknumber | 0 relblocknumber | 11 xid | 341 resource_manager | Btree record_type | INSERT_LEAF record_length | 64 main_data_length | 2 block_data_length | 16 block_fpi_length | 0 block_fpi_info | description | off: 46 block_data | \x00002a00070010402630000070696400 block_fpi_data |
此示例涉及仅包含一个块引用的 WAL 记录,但许多 WAL 记录包含多个块引用。由
pg_get_wal_block_info
输出的行保证具有start_lsn
和block_id
值的唯一组合。此处显示的大部分信息与
pg_get_wal_records_info
在给定相同参数的情况下显示的输出相匹配。但是,pg_get_wal_block_info
通过为每个块引用输出一行将每个 WAL 记录中的信息展开成扩展形式,因此某些详细信息是在块引用级别而不是在整个记录级别跟踪的。此结构对于跟踪各个块如何随时间变化的查询非常有用。请注意,不带块引用的记录(例如,COMMIT
WAL 记录)不会返回任何行,因此pg_get_wal_block_info
实际返回的行可能 少于pg_get_wal_records_info
。参数
reltablespace
、reldatabase
和relfilenode
分别引用pg_tablespace
.oid
、pg_database
.oid
和pg_class
.relfilenode
。字段relforknumber
是块引用的关系中的 fork 号码;有关详细信息,请参见common/relpath.h
。提示
函数
pg_filenode_relation
(请参见 表 9.97)可以帮助您确定在原始执行期间修改了哪个关系。客户端可以避免实体化块数据的开销。这可能会使函数执行速度显著提升。当
show_data
设置为false
时,将省略block_data
和block_fpi_data
值(即,对于返回的所有行,block_data
和block_fpi_data
OUT
参数均为NULL
)。显然,此优化仅适用于实际上不需要块数据的查询。如果
start_lsn
不可获取,则该函数会引发错误。pg_get_wal_stats(start_lsn pg_lsn, end_lsn pg_lsn, per_record boolean DEFAULT false) returns setof record
#获取
start_lsn
和end_lsn
之间所有有效 WAL 记录的统计信息。默认情况下,它每种resource_manager
类型返回一行。当per_record
设置为true
时,它每种record_type
返回一行。例如postgres=# SELECT * FROM pg_get_wal_stats('0/1E847D00', '0/1E84F500') WHERE count > 0 AND "resource_manager/record_type" = 'Transaction' LIMIT 1; -[ RECORD 1 ]----------------+------------------- resource_manager/record_type | Transaction count | 2 count_percentage | 8 record_size | 875 record_size_percentage | 41.23468426013195 fpi_size | 0 fpi_size_percentage | 0 combined_size | 875 combined_size_percentage | 2.8634072910530795
如果
start_lsn
不可获取,则该函数会引发错误。
F.37.2. 作者#
Bharath Rupireddy<[[email protected]](/cdn-cgi/l/email-protection#debcb6bfacbfaab6f0acabaeb7acbbbabaa7b8b1acaeb1adaab9acbbad9eb9b3bfb7b2f0bdb1b3)>