I'd recently been thinking about monitoring how many bytes behind a logical slot was and realized that's not really possible to compute currently. That's easy enough with a physical slot because we can get the current WAL LSN easily enough and the slot exposes the current LSN positions of the slot. However for logical slots that naive computation isn't quite right. The logical slot can't flush past the last commit, so even if there's 100s of megabytes of unflushed WAL on the slot there may be zero lag (in terms of what's possible to process).
I've attached a simple patch (sans tests and documentation) to get feedback early. After poking around this afternoon it seemed to me that the simplest approach was to hook into the commit timestamps infrastructure and store the commit's XLogRecPtr in the cache of the most recent value (but of course don't write it out to disk). That the downside of making this feature dependent on "track_commit_timestamps = on", but that seems reasonable: 1. Getting the xid of the last commit is similarly dependent on commit timestamps infrastructure. 2. It's a simple place to hook into and avoids new shared data and locking. Thoughts? Thanks, James Coleman
v1-0001-Expose-LSN-of-last-commit-via-pg_last_committed_x.patch
Description: Binary data