On Mon, Jan 17, 2022 at 4:34 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2022-Jan-14, James Coleman wrote:
>
> > The logical slot can't flush past the
> > last commit, so even if there's 100s of megabytes of unflushed WAL on
> > the slot there may be zero lag (in terms of what's possible to
> > process).
> >
> > I've attached a simple patch (sans tests and documentation) to get
> > feedback early. After poking around this afternoon it seemed to me
> > that the simplest approach was to hook into the commit timestamps
> > infrastructure and store the commit's XLogRecPtr in the cache of the
> > most recent value (but of course don't write it out to disk).
>
> Maybe it would work to have a single LSN in shared memory, as an atomic
> variable, which uses monotonic advance[1] to be updated. Whether this is
> updated or not would depend on a new GUC, maybe track_latest_commit_lsn.
> Causing performance pain during transaction commit is not great, but at
> least this way it shouldn't be *too* a large hit.
>
> [1] part of a large patch at
> https://www.postgresql.org/message-id/202111222156.xmo2yji5ifi2%40alvherre.pgsql
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.
Thanks,
James Coleman