Open Krysztophe opened 3 years ago
On a replica with log shipping only, the ''hot_standby_delta'' service gives strange results:
receive delta service:nagios_defo13_2 | 656.00 MiB | 100.00 MiB | 1024.00 MiB replay delta service:nagios_defo13_2 | 0.00 B | 200.00 MiB | 2.00 GiB
In fact , for log shipping, pg_last_wal_receive_lsn is stuck at the end of the recovery.
# SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn() ; pg_last_wal_receive_lsn | pg_last_wal_replay_lsn -------------------------+------------------------ 1C/EB0001C0 | 1D/11000000
It seems that replacing ''coalesce''' by ''greatest'' in the query works (see https://github.com/OPMDG/check_pgactivity/blob/8009e0e6ab209578edde25f8bd58b80fc2a06955/check_pgactivity#L4227 )
Option: get rid of the "receive" perfdata when pg_last_wal_receive_lsn < pg_last_wal_replay_lsn
BTW this cas occurs only after a switch from streaming to log shipping without restarting the replica.
On a replica with log shipping only, the ''hot_standby_delta'' service gives strange results:
In fact , for log shipping, pg_last_wal_receive_lsn is stuck at the end of the recovery.
It seems that replacing ''coalesce''' by ''greatest'' in the query works (see https://github.com/OPMDG/check_pgactivity/blob/8009e0e6ab209578edde25f8bd58b80fc2a06955/check_pgactivity#L4227 )
Option: get rid of the "receive" perfdata when pg_last_wal_receive_lsn < pg_last_wal_replay_lsn