On Mon, Mar 27, 2023 at 4:59 PM Peter Geoghegan <p...@bowt.ie> wrote: > Looking at this now, with the intention of committing it for 16.
Attached revision v7 adjusts the column order. This is still WIP, but
gives a good idea of the direction I'm going in.
v7 makes the column output look like this:
pg@regression:5432 [1209761]=# select * from
pg_get_wal_block_info('0/10D8280', '0/10D82B8');
┌─[ RECORD 1 ]─────┬──────────────────────────────────────────────────┐
│ start_lsn │ 0/10D8280 │
│ end_lsn │ 0/10D82B8 │
│ prev_lsn │ 0/10D8208 │
│ blockid │ 0 │
│ reltablespace │ 1,663 │
│ reldatabase │ 1 │
│ relfilenode │ 2,610 │
│ relforknumber │ 0 │
│ relblocknumber │ 0 │
│ xid │ 0 │
│ resource_manager │ Heap2 │
│ record_type │ PRUNE │
│ record_length │ 56 │
│ main_data_length │ 8 │
│ block_fpi_length │ 0 │
│ block_fpi_info │ ∅ │
│ description │ snapshotConflictHorizon 10 nredirected 0 ndead 1 │
│ block_data │ \x2b00 │
│ fpi_data │ ∅ │
└──────────────────┴──────────────────────────────────────────────────┘
Few things to note here:
* blockid is now given more prominence, in that it appears just after
the LSN related output params.
The idea is that the blockid is conceptually closer to the LSN stuff.
* There is now a smallint relblocknumber, for consistency with
pg_buffercache. This replaces the previous text column.
As I mentioned earlier on, I don't think that a text based output
param adds much.
* The integer fields record_length, main_data_length, block_fpi_length
all now all appear together. This is for consistency with the similar
output params from the other function.
v7 allows block_fpi_length to be 0 instead of NULL, for consistency
with the fpi_length param from the other function. The intention is to
make it relatively obvious which information "comes from the record"
and which information "comes from the block reference".
* The block_fpi_info output param appears right after block_fpi_info.
This is not very verbose, and I find that it is hard to find by
scrolling horizontally in pspg if it gets placed after either
block_data or fpi_data, which tend to have at least some huge/wide
outputs. It seemed sensible to place block_fpi_info next to the param
I'm now calling block_fpi_length, after it was moved next to the other
"length" fields.
How do people feel about this approach? I'll need to write
documentation to help the user to understand what's really going on
here.
--
Peter Geoghegan
v7-0001-Emit-WAL-record-info-via-pg_get_wal_block_info.patch
Description: Binary data
