On Tue, Jan 18, 2022 at 8:05 PM Andres Freund <and...@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
