Re: Add last commit LSN to pg_last_committed_xact()

From: James Coleman <jtc331(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add last commit LSN to pg_last_committed_xact()
Date: 2022-01-18 18:41:51
Message-ID: CAAaqYe-GDRK7t_htVc+EJS+iCAJRoNLOXUO9sHvV_-LcFS=RFQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 18, 2022 at 12:50 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-01-18 18:48:24 Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
Previous Message Tom Lane 2022-01-18 18:32:55 Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout, connect_timeout and keepalive settings