mirror of
https://github.com/neondatabase/neon.git
synced 2025-12-26 07:39:58 +00:00
cf7a596a15
There are quite a few benefits to this approach:
- Reduce config duplication
- The two sql_exporter configs were super similar with just a few
differences
- Pull SQL queries into standalone files
- That means we could run a SQL formatter on the file in the future
- It also means access to syntax highlighting
- In the future, run different queries for different PG versions
- This is relevant because right now, we have queries that are failing
on PG 17 due to catalog updates
Signed-off-by: Tristan Partin <tristan@neon.tech>
7 lines
363 B
SQL
7 lines
363 B
SQL
-- We use a GREATEST call here because this calculation can be negative. The
|
|
-- calculation is not atomic, meaning after we've gotten the receive LSN, the
|
|
-- replay LSN may have advanced past the receive LSN we are using for the
|
|
-- calculation.
|
|
|
|
SELECT GREATEST(0, pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn())) AS replication_delay_bytes;
|