On Tue, Jan 18, 2022 at 12:50 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2022-Jan-17, James Coleman wrote:
>
> > I'd be happy to make it a separate GUC, though it seems adding an
> > additional atomic access is worse (assuming we can convince ourselves
> > putting this into the commit timestamps infrastructure is acceptable)
> > given here we're already under a lock.
>
> I was thinking it'd not be under any locks ... and I don't think it
> belongs under commit timestamps either.
I'm not sure if you saw the other side of this thread with Robert, but
my argument is basically that the commit_ts infrastructure already
currently does more than just record commit timestamps for future use,
it also includes what looks to me like a more general "last commit
metadata" facility (which is not actually at all necessary to the
storing of commit timestamps). It might make sense to refactor this
somewhat so that that's more obvious, but I'd like to know if it looks
that way to you as well, and, if so, does that make it make more sense
to rely on the existing infrastructure rather than inventing a new
facility?
Thanks,
James Coleman