Re: Add last commit LSN to pg_last_committed_xact() - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Add last commit LSN to pg_last_committed_xact()
Date
Msg-id 202201181407.gpu6ivyddgkw@alvherre.pgsql
Whole thread Raw
In response to Re: Add last commit LSN to pg_last_committed_xact()  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2022-Jan-17, Robert Haas wrote:

> On Mon, Jan 17, 2022 at 4:34 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> > 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.

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/



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: missing indexes in indexlist with partitioned tables
Next
From: Robert Haas
Date:
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations