为了监视从一个PostgreSQL服务器到另一个PostgreSQL服务器的复制延迟，我使用一个简单的脚本，在主服务器上运行查询“SELECT pg_current_xlog_location（）”，在从服务器上运行“SELECT pg_last_xlog_receive_location（）”。 然后我把结果从hex转换成十进制，并计算差异来获得复制延迟。
我的问题是我无法弄清楚这个xlog_location返回什么单位。任何人都可以解释这一点？
“单位不重要”（但是如果你好奇，这些单位在交易日志中的位置 – 这里有一些讨论）。
重要的是要注意日志位置和时间之间没有正相关关系。
大交易可能会在短时间内将日志大幅度移动。
轻度使用的数据库可能会在相同的日志点数小时（或更长时间）。
你可以从这个测量中知道你在日志里面有多远（即你是否与主服务器同步，大概需要发送/重播多less数据）。
Postgres Wiki中有更多的讨论，但是根据你的问题来看，我认为你已经阅读了这个页面 – 在Postgres的pgsql-admin邮件列表中询问是否值得澄清（你也许会变得更好回答比我给你的，也许能够更新Postgres Wiki 🙂
日志单元是以字节为单位的（尽pipe它们是相对的 – 所以它们对于测量除“偏移量”以外的任何东西都是没有用的，并且在有许多被跳过的字节的地方有时可以是“跳跃”），其值被计算为：
如果你输出：SELECT pg_current_xlog_location（），你会得到如下的东西：
70/A9002358 “/”之前的部分乘以“ff000000”并添加到第二部分：
在python的说法（将hex转换为int（'HEX'，16）函数）可能看起来像这样：
int('ff000000',16)*int('70',16) + int('A9002358',16)
您可以使用以下命令查找当前使用的WAL文件名：
select pg_xlogfile_name(pg_current_xlog_insert_location());
从技术上讲，如果从服务器需要的日志文件在主服务器上仍然可用，则从服务器可以跟上主服务器。 当然，如果从服务器慢慢地重播，它可能永远不会跟上来，但是你可以使用下面的查询来测量它是“追赶”还是“落后”（有点）
在奴隶你可以得到使用查询的时间延迟的想法：
SELECT extract(epoch from (now()- pg_last_xact_replay_timestamp())) AS time_lag;
但是，返回的数字实际上是“自从上次重放交易以来的时间” – 所以如果主人在一段时间内没有交易，那么“时间”可能使得它看起来像奴隶落后（当它现实，它被赶上了，但没有交易的主人。）