Horton

Re: Add pg_walinspect function with block info columns

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: bharath.rupireddyforpostgres@gmail.com, michael@paquier.xyz, melanieplageman@gmail.com, boekewurm+postgres@gmail.com, pgsql-hackers@postgresql.org
Date: 2023-03-20T23:51:19Z
Lists: pgsql-hackers 
On Mon, Mar 20, 2023 at 4:34 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I agree. A little redundancy is better when the alternative is fragile
> code, and I'm pretty sure that that applies here -- there won't be
> very many duplicated lines, and the final code will be significantly
> clearer. There can be a comment about keeping GetWALRecordInfo and
> GetWALBlockInfo in sync.

The new pg_get_wal_block_info outputs columns in an order that doesn't
seem like the most useful possible order to me. This gives us another
reason to have separate GetWALRecordInfo and GetWALBlockInfo utility
functions rather than sharing logic for building output tuples.

Specifically, I think that pg_get_wal_block_info should ouput the
"primary key" columns first:

reltablespace, reldatabase, relfilenode, blockid, start_lsn, end_lsn

Next comes the columns that duplicate the columns output by
pg_get_wal_records_info, in the same order as they appear in
pg_get_wal_records_info. (Obviously this won't include block_ref).

-- 
Peter Geoghegan

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()