Re: RFC: Detailed reorder buffer stats dumps - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: RFC: Detailed reorder buffer stats dumps
Date
Msg-id CAGRY4nz13DvpuEVAQZUk9m9-SaZ9JdD7Jz5C66j8cA5Y7ZkY8g@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Detailed reorder buffer stats dumps  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, 6 May 2021 at 19:40, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, May 6, 2021 at 9:54 AM Craig Ringer <craig@2ndquadrant.com> wrote:
> At the least it'd be helpful to have pg_stat_replication (or a new related auxiliary view like pg_stat_logical_decoding) show
>
> - walsender total bytes sent this session
> - number of txns processed this txn
>

You might be able to derive some of the above sorts of stats from the
newly added pg_stat_replication_slots [1].


That's a huge improvement that I managed to totally miss the discussion of and work on. Thanks. It'll be a significant help.
'
> - number txns filtered out by output plugin this session
> - oldest xid in reorder buffer
> - reorder buffer number of txns
> - reorder buffer total size (in-memory and total inc spilled)
> - reorderbuffercommit current xid, last change lsn, total buffered size of current tx, total bytes of buffer processed so far within the current txn, and commit lsn if known, only when currently streaming a txn from reorderbuffercommit

These are less statistical in nature, and more about the current activity of the walsender and logical decoding state. I'm not sure if it'd make much sense to tack them on to pg_stat_replication_slots, especially as that'd also mean they were quite delayed.

But it probably isn't worth the effort of exposing this info in a new view.

With the higher level info now available in pg_stat_replication_slots, I think I might look into exposing these finer details via trace markers for use with perf / systemtap  / etc instead.

A digression, but: It's a real shame that such tools don't give us a way to read specific tagged regions of memory with the same ease they let us probe function calls though. You generally need gdb to read the value of a global, or a moderately funky systemtap script. There's no convenient equivalent to SDT markers (TRACE_FOO) to tag variables. Wouldn't it be nice if we could

     perf watch postgres:walsender_reorderbuffer_oldest_xid

or something like that?

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Dump public schema ownership & seclabels
Next
From: Peter Eisentraut
Date:
Subject: Re: Add index OID macro argument to DECLARE_INDEX