Subject: Re: Add last commit LSN to pg_last_committed_xact()

From: Robert Haas <[email-masked]>
Date: Mon, 17 Jan 2022 16:55:10 -0500

On Mon, Jan 17, 2022 at 4:34 PM Alvaro Herrera <[email-masked]> wrote:
> On 2022-Jan-14, James Coleman wrote:
> > 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).
>
> Maybe it would work to have a single LSN in shared memory, as an atomic
> variable, which uses monotonic advance[1] to be updated.  Whether this is
> updated or not would depend on a new GUC, maybe track_latest_commit_lsn.
> Causing performance pain during transaction commit is not great, but at
> least this way it shouldn't be *too* a large hit.

I don't know if it would or not, but it's such a hot path that I find
the idea a bit worrisome. Atomics aren't free - especially inside of a
loop.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 18 Jan 2022 11:07:19 -0300

> the idea a bit worrisome. Atomics aren't free - especially inside of a

I think the aspect to worry about the most is what happens when the
feature is disabled.  The cost for that should be just one comparison,
which I think can be optimized by the compiler fairly well.  That should
be cheap enough.  People who enable it would have to pay the cost of the
atomics, which is of course much higher.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/