Re: Add pg_walinspect function with block info columns

On Mon, Mar 27, 2023 at 7:40 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Attached revision v7 adjusts the column order. This is still WIP, but
> gives a good idea of the direction I'm going in.

A couple of small tweaks to this appear in the attached revision, v8.
Now it looks like this:

pg@regression:5432 [1294231]=# select * from
pg_get_wal_block_info('0/10E9D80' , '0/10E9DC0');
┌─[ RECORD 1 ]──────┬────────────────────────────────────┐
│ start_lsn         │ 0/10E9D80                          │
│ end_lsn           │ 0/10E9DC0                          │
│ prev_lsn          │ 0/10E9860                          │
│ blockid           │ 0                                  │
│ reltablespace     │ 1,663                              │
│ reldatabase       │ 1                                  │
│ relfilenode       │ 2,690                              │
│ relforknumber     │ 0                                  │
│ relblocknumber    │ 5                                  │
│ xid               │ 117                                │
│ resource_manager  │ Btree                              │
│ record_type       │ INSERT_LEAF                        │
│ record_length     │ 64                                 │
│ main_data_length  │ 2                                  │
│ block_data_length │ 16                                 │
│ block_fpi_length  │ 0                                  │
│ block_fpi_info    │ ∅                                  │
│ description       │ off 14                             │
│ block_data        │ \x00005400020010001407000000000000 │
│ block_fpi_data    │ ∅                                  │
└───────────────────┴────────────────────────────────────┘

This is similar to what I showed recently for v7. Just two changes:

* The parameter formerly called fpi_data is now called block_fpi_data,
to enforce the idea that it's block specific (and for consistency with
the related block_fpi_length param).

* There is now a new column, which makes the size of block_data
explicit: block_data_length

This made sense on consistency grounds, since we already had a
block_fpi_length. But it also seems quite useful. In this example, I
can immediately see that this INSERT_LEAF record needed 2 bytes for
the block offset number (indicating off 14), and 16 bytes of block
data for the IndexTuple data itself. There is a more recognizable
pattern to things, since the size of tuples for a given relation tends
to be somewhat homogenous. block_data_length also seems like it could
provide users with a handy way of filtering out definitely-irrelevant
block references.

-- 
Peter Geoghegan