方案1：

主库查询

SELECT * FROM pg_stat_replication;

NOTE1：PostgreSQL 10及以后版本 pg_stat_replication视图增加了write_lag，flush_lag，replay_lag。分别表示从库wal日志写入(写入到操作系统缓存)延迟，从库wal日志刷新延迟(wal日志刷入磁盘)，从库wal日志应用延迟。

NOTE2：如果从库跟主库复制已经出现问题，比如备库需要的wal日志在主库已经被删除，则主库中该表为空
2024-05-23 14:13:56.375 CST [22978] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000200000141000000C8 has already been removed

方案2：

从库查询

NOTE1：postgres_exporter 0.14 及 0.15 版本的备库延迟监控策略

NOTE2：主库宕机，或者主备wal日志同步异常时，pg_last_wal_receive_lsn () = pg_last_wal_replay_lsn () 则在从库查询也会显示无延迟。

NOTE3：pg_last_xact_replay_timestamp 函数显示备库最近WAL日志应用时间， 通过与当前时间比较可粗略计算主备库延时，这种方式的优点是即使主库宕机，也可以大概判断主备延时。 缺点是如果主库上只有读操作，主库不会发送WAL日志流到备库，pg_last_xact_replay_timestamp函数返回的结果就是一个静态的时间， 这个公式的判断结果就不严谨了

SELECTCASEWHEN NOT pg_is_in_recovery() THEN 0WHEN pg_last_wal_receive_lsn () = pg_last_wal_replay_lsn () THEN 0ELSE GREATEST (0, EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())))END AS lag,CASEWHEN pg_is_in_recovery() THEN 1ELSE 0END as is_replica;