Re: Add last commit LSN to pg_last_committed_xact()

From: James Coleman <jtc331(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add last commit LSN to pg_last_committed_xact()
Date: 2022-01-20 02:23:12
Message-ID: CAAaqYe-QtHF1CExgvyQZdkdZx-0KCyRsu+ATJTqurWU4Ekt2Vg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 18, 2022 at 9:19 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > + LWLockAcquire(ProcArrayLock, LW_SHARED);
> > + lsn = ShmemVariableCache->finishedProcsLastCommitLSN;
> > + for (index = 0; index < ProcGlobal->allProcCount; index++)
> > + {
> > + XLogRecPtr procLSN = ProcGlobal->allProcs[index].lastCommitLSN;
> > + if (procLSN > lsn)
> > + lsn = procLSN;
> > + }
> > + LWLockRelease(ProcArrayLock);
>
> I think it'd be better to go through the pgprocnos infrastructure, so that
> only connected procs need to be checked.
>
> LWLockAcquire(ProcArrayLock, LW_SHARED);
> for (i = 0; i < arrayP->numProcs; i++)
> {
> int pgprocno = arrayP->pgprocnos[i];
> PGPROC *proc = &allProcs[pgprocno];
>
> if (proc->lastCommitLSN > lsn)
> lsn =proc->lastCommitLSN;
> }
>
>
> > diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
> > index a58888f9e9..2a026b0844 100644
> > --- a/src/include/storage/proc.h
> > +++ b/src/include/storage/proc.h
> > @@ -258,6 +258,11 @@ struct PGPROC
> > PGPROC *lockGroupLeader; /* lock group leader, if I'm a member */
> > dlist_head lockGroupMembers; /* list of members, if I'm a leader */
> > dlist_node lockGroupLink; /* my member link, if I'm a member */
> > +
> > + /*
> > + * Last transaction metadata.
> > + */
> > + XLogRecPtr lastCommitLSN; /* cache of last committed LSN */
> > };
>
> We do not rely on 64bit integers to be read/written atomically, just 32bit
> ones. To make this work for older platforms you'd have to use a
> pg_atomic_uint64. On new-ish platforms pg_atomic_read_u64/pg_atomic_write_u64
> end up as plain read/writes, but on older ones they'd do the necessarily
> locking to make that safe...

All right, here's an updated patch.

The final interface (new function or refactor the existing not to rely
on commit_ts) is still TBD (and I'd appreciate input on that from
Alvaro and others).

Thanks,
James Coleman

Attachment Content-Type Size
v3-0001-Expose-LSN-of-last-commit-via-pg_last_committed_x.patch text/x-patch 10.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2022-01-20 02:34:34 Re: Document atthasmissing default optimization avoids verification table scan
Previous Message Peter Smith 2022-01-20 02:21:06 Re: row filtering for logical replication