On Tue, Jan 18, 2022 at 8:05 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2022-01-18 18:31:42 -0500, James Coleman wrote:
> > One other question on this: if we went with this would you expect a
> > new function to parallel pg_last_committed_xact()?
>
> I don't think I have an opinion the user interface aspect.
>
>
> > Or allow the xid and lsn in the return of pg_last_committed_xact()
> > potentially not to match (of course xid might also not be present if
> > track_commit_timestamps isn't on)? Or would you expect the current xid and
> > timestamp use the new infrastructure also?
>
> When you say "current xid", what do you mean?
I mean the existing commitTsShared->xidLastCommit field which is
returned by pg_last_committed_xact().
> I think it might make sense to use the new approach for all of these.
I think that would mean we could potentially remove commitTsShared,
but before doing so I'd like to know if that'd break existing
consumers.
Alvaro: You'd mentioned a use case in pglogical; if we moved the
xidLastCommit (and possibly even the cached last timestamp) out of
commit_ts.c (meaning it'd also no longer be under the commit ts lock)
would that be a problem for the current use (whether in lock safety or
in performance)?
Thanks,
James Coleman
