In `pgStatWalReceiverQueryTemplate`, the order of the columns (when `hasFlushedLSN == true`) is:
- ...
- `receive_start_lsn`
- `flushed_lsn`
- `receive_start_tli`
- ...
However, columns were scanned in this order:
- ...
- `receive_start_lsn` -> `receiveStartLsn`
- `receive_start_tli` -> `flushedLsn` (!)
- `flushed_lsn` -> `receiveStartTli` (!)
- ...
This incorrect hydration of variables also manifests as swapped values for the
`pg_stat_wal_receiver_flushed_lsn` and `pg_stat_wal_receiver_receive_start_tli` metrics.
This seems to be a bug that has existed since the initial implementation:
- 2d7e152751
- https://github.com/prometheus-community/postgres_exporter/pull/844
In this patch, I'm:
- fixing the `.Scan()`, so that it hydrates variables in the correct order
- adjusting the order in which metrics are pushed out to the channel,
to follow the order we consume them in
(.., `receive_start_lsn`, `flushed_lsn`, `receive_start_tli`, ..)
- adjusting the walreceiver tests, to follow the new order (which matches .`Scan()`)
- fixing a small identation issue in `pgStatWalReceiverQueryTemplate`
Signed-off-by: Slavi Pantaleev <slavi@devture.com>
In a streaming replication setup that was created without replication
manager (`repmgr`), the `stat_wal_receiver` collector does not return
any metrics, because one value it wants to export is not present.
This is rather overly opinionated. The missing metric is comparatively
uninteresting and does not justify discarding all the others. And
replication setups created without `repmgr` are not exactly rare.
This commit makes the one relevant metric optional and simply skips it
if the respective value cannot be determined.
Signed-off-by: Conrad Hoffmann <ch@bitfehler.net>
* Fix bugs mentioned in #908
These collectors are disabled by default, so unless enabled, they are not tested regularly.
Signed-off-by: Joe Adams <github@joeadams.io>
---------
Signed-off-by: Joe Adams <github@joeadams.io>
