From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | RFC: Detailed reorder buffer stats dumps |
Date: | 2021-05-05 10:33:27 |
Message-ID: | CAMsr+YFSG5UF=kUfYX444-X2tDAXdxuDyzW1+hi=7AUmpbOpHA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all
I'm thinking of piggy-backing on the approach used in the "Get memory
contexts of an arbitrary backend process" patch in order to provide access
to detailed reorder buffer content statistics from walsenders on request.
Right now the reorder buffer is mostly a black-box. I mostly rely on gdb or
on dynamic probes (perf, systemtap) to see what it's doing. I intend a
patch soon to add a couple of fields to struct WalSnd to report some very
coarse reorder buffer stats - at least oldest buffered xid, number of
buffered txns, total bytes of buffered txns in memory, total bytes of
buffered txns spilled to disk.
But sometimes what I really want is details on the txns that're in the
reorder buffer, and that's not feasible to export via always-enabled
reporting like struct WalSnd. So I'm thinking that the same approach used
for the memory context stats patch might work well for asking the walsender
for a detailed dump of reorder buffer contents. Something like a
per-buffered-txn table of txn topxid, start-lsn, most recent change lsn,
number of changes, number of subxids, number of invalidations, number of
catalog changes, buffer size in memory, buffer size spilled to disk.
Anyone drastically opposed to the idea?
(I know I have to finish up with the LWLock tracepoint patchset first, this
is a RFC at this stage).
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Luzanov | 2021-05-05 10:58:59 | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
Previous Message | Michael Paquier | 2021-05-05 10:30:45 | Re: Small issues with CREATE TABLE COMPRESSION |