Add last commit LSN to pg_last_committed_xact()

From: James Coleman <jtc331(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Add last commit LSN to pg_last_committed_xact()
Date: 2022-01-15 00:42:27
Message-ID: CAAaqYe9QBiAu+j8rBun_JKBRe-3HeKLUhfVVsYfsxQG0VqLXsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v1-0001-Expose-LSN-of-last-commit-via-pg_last_committed_x.patch application/octet-stream 7.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-01-15 00:51:01 Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
Previous Message Thomas Munro 2022-01-15 00:40:59 Re: Why is src/test/modules/committs/t/002_standby.pl flaky?