| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, satyanarlapuram(at)gmail(dot)com, marvin_liang(at)qq(dot)com, actyzhang(at)outlook(dot)com, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
| Subject: | Re: pg_walinspect - a new extension to get raw WAL data and WAL stats |
| Date: | 2021-10-06 17:23:33 |
| Message-ID: | 202110061723.h6sap4ep3ij3@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2021-10-06 17:28:35 | Re: Role Self-Administration |
| Previous Message | Stephen Frost | 2021-10-06 17:20:10 | Re: Role Self-Administration |