Horton

Re: Add pg_walinspect function with block info columns

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Melanie Plageman <melanieplageman@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-03-15T07:00:22Z
Lists: pgsql-hackers 
On Wed, Mar 15, 2023 at 12:13:56PM +0530, Bharath Rupireddy wrote:
> How about something like the attached? It adds the per-record columns
> to pg_get_wal_block_info() avoiding "possibly expensive" joins with
> pg_get_wal_records_info().
> 
> With this, pg_get_wal_records_info() too will be useful for users
> scanning WAL at record level. That is to say that we can retain both
> pg_get_wal_records_info() and pg_get_wal_block_info().

FWIW, I am not convinced that there is any need to bloat more the
attributes of these functions, as filters for records could basically
touch all the fields returned by pg_get_wal_records_info().  What
about adding an example in the docs with the LATERAL query I mentioned
previously?
--
Michael

Commits

  1. Add show_data option to pg_get_wal_block_info.

  2. Show record information in pg_get_wal_block_info.

  3. Fix recent pg_walinspect fpi_length bug.

  4. Improve a few things in pg_walinspect

  5. Rework design of functions in pg_walinspect

  6. pg_walinspect: pg_get_wal_fpi_info() -> pg_get_wal_block_info()