We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
check_pgactivity/check_pgactivity
Line 4227 in 8009e0e
Option: get rid of the "receive" perfdata when pg_last_wal_receive_lsn < pg_last_wal_replay_lsn
The text was updated successfully, but these errors were encountered:
BTW this cas occurs only after a switch from streaming to log shipping without restarting the replica.
Sorry, something went wrong.
Krysztophe
No branches or pull requests
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
check_pgactivity/check_pgactivity
Line 4227 in 8009e0e
Option: get rid of the "receive" perfdata when pg_last_wal_receive_lsn < pg_last_wal_replay_lsn
The text was updated successfully, but these errors were encountered: