Re: Add last commit LSN to pg_last_committed_xact()

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: James Coleman <jtc331(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add last commit LSN to pg_last_committed_xact()
Date: 2022-01-17 21:20:11
Message-ID: CA+TgmoZiY3aRMG_vtOpELqsnYiiStiG=SUqkHJ3KCLSWwsZjxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 14, 2022 at 7:42 PM James Coleman <jtc331(at)gmail(dot)com> wrote:
> 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?

It doesn't seem great to me. It's making commit_ts do something other
than commit timestamps, which looks kind of ugly.

In general, I'm concerned about the cost of doing something like this.
Extra shared memory updates as part of the process of committing a
transaction are not (and can't be made) free.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-01-17 21:22:19 Re: a misbehavior of partition row movement (?)
Previous Message Andrew Dunstan 2022-01-17 21:13:28 Re: Adding CI to our tree