Re: Add last commit LSN to pg_last_committed_xact()

On Mon, Jan 17, 2022 at 4:20 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> 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.

I wondered about that, but commit_ts already does more than commit
timestamps by recording the xid of the last commit.

For that matter, keeping a cache of last commit metadata in shared
memory is arguably not obviously implied by "track_commit_timestamps",
which leads to the below...

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

It seems to me that to the degree there's a hot path concern here we
ought to separate out the last commit metadata caching from the
"track_commit_timestamps" feature (at least in terms of how it's
controlled by GUCs). If that were done we could also, in theory, allow
controlling which items are tracked to reduce hot path cost if only a
subset is needed. For that matter it'd also allow turning on this
metadata caching without enabling the commit timestamp storage.

I'm curious, though: I realize it's in the hot path, and I realize
that there's an accretive cost to even small features, but given we're
already paying the lock cost and updating memory in what is presumably
the same cache line, would you expect this cost to be clearly
measurable?

Thanks,
James Coleman