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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, boekewurm+postgres@gmail.com, melanieplageman@gmail.com, pgsql-hackers@postgresql.org, pg@bowt.ie
Date: 2023-03-08T10:53:13Z
Lists: pgsql-hackers 
On Wed, Mar 08, 2023 at 04:01:56PM +0530, Bharath Rupireddy wrote:
> I understand that performance is critical here but we need to ensure
> memory is used wisely. Therefore, I'd still vote to free at least the
> major contributors here, that is, pfree(raw_data);, pfree(raw_page);
> and pfree(flags); right after they are done using. I'm sure pfree()s
> don't hurt more than resetting memory context for every block_id.

Okay by me to have intermediate pfrees between each block scanned if
you feel strongly about it.

> I think we need to output block data length (blk->data_len) similar to
> fpilen to save users from figuring out how to get the length of a
> bytea column. This will also keep block data in sync with FPI info.

length() works fine on bytea, so it can be used on the block data.
fpilen is a very different matter as it would be the length of a page
without a hole, or just something compressed.
--
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()