On Mon, Mar 27, 2023 at 12:42 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > Thanks. Here's the v6 patch (last patch that I have with me for > pg_walinspect) for adding per-record info to pg_get_wal_block_info. > Note that I addressed all review comments received so far. Any > thoughts?
Looking at this now, with the intention of committing it for 16. In addition to what I said a little while ago about the forknum parameter and parameter ordering, I have a concern about the data type: perhaps the forknum paramater should be declared as "relforknumber smallint", instead of using text? That would match the approach taken by pg_buffercache, and would be more efficient. I don't think that using a text column with the fork name adds too much, since this is after all supposed to be a tool used by experts. Plus it's usually pretty clear what it is from context. Not that many WAL records touch the visibility map, and those that do make it relatively obvious which block is from the VM based on other details. Details such as blockid and relblocknumber (the VM is approximately 32k times smaller than the heap). Once I see that the record is (say) a VISIBLE record, I'm already looking at the order of each block reference, and maybe at relblocknumber -- I'm not likely to visually scan the forknum column at all. -- Peter Geoghegan
