Horton

Re: pg_walinspect - a new extension to get raw WAL data and WAL stats

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Jeremy Schneider <schneider@ardentperf.com>
Cc: Bruce Momjian <bruce@momjian.us>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, satyanarlapuram@gmail.com, marvin_liang@qq.com, actyzhang@outlook.com, Ashutosh Sharma <ashu.coek88@gmail.com>
Date: 2021-10-06T17:23:33Z
Lists: pgsql-hackers 
On 2021-Oct-06, Jeremy Schneider wrote:

> Well this whole conversation is just theoretical anyway until the code
> is shared.  :)  But if Bharath is writing functions to decode WAL, then
> wouldn't we just have pg_waldump use these same functions in order to
> avoid duplicating code?

Actually, a lot of the code is already shared, since the rmgrdesc
routines are in src/backend.  Keep in mind that it was there before
pg_xlogdump existed, to support WAL_DEBUG.  When pg_xlogdump was added,
what we did was allow that backend-only code be compilable in a frontend
environment.  Also, we already have xlogreader.

So pg_waldump itself is mostly scaffolding to let the frontend
environment get argument values to pass to backend-enabled code.  The
only really interesting, novel thing is the --stats mode ... and I bet
you can write that with some SQL-level aggregation of the raw data, no
need for any C code.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/

Commits

  1. Doc build fix: remove tab from filelist.sgml.

  2. Add contrib/pg_walinspect.

  3. Simplify SRFs using materialize mode in contrib/ modules

  4. Invent "trusted" extensions, and remove the pg_pltemplate catalog.