On Mon, Mar 27, 2023 at 7:40 PM Peter Geoghegan <p...@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
v8-0001-Emit-WAL-record-info-via-pg_get_wal_block_info.patch
Description: Binary data
