On Mon, Mar 27, 2023 at 7:47 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > Hm, agreed. Changed in the attached v7-0002 patch. We can as well > write a case statement in the create function SQL to output forkname > instead forknumber, but I'd stop doing that to keep in sync with > pg_buffercache.
I just don't see much value in any textual representation of fork name, however generated. In practice it's just not adding very much useful information. It is mostly useful as a way of filtering block references, which makes simple integers more natural. > Oh, thanks for finding it out. Fixed in the attached v7-0001 patch. I > also removed the "invalid fork number" error as users can figure that > out if at all the fork number is wrong. Pushed just now. > On the ordering of the columns, I kept start_lsn, end_lsn and prev_lsn > first and then the rel** columns (this rel** columns order follows > pg_buffercache) and then block data related columns. Michael and > Kyotaro are of the opinion that it's better to keep LSNs first to be > consistent and also given that this function is WAL related, it makes > sense to have LSNs first. Right, but I didn't change that part in the revision of the patch I posted. Those columns still came first, and were totally consistent with the pg_get_wal_record_info function. I think that there was a "mid air collision" here, where we both posted patches that we each called v7 within minutes of each other. Just to be clear, I ended up with a column order as described here in my revision: https://postgr.es/m/CAH2-WzmzO-AU4QSbnzzANBkrpg=4cuod3scvtv+7x65e+qk...@mail.gmail.com It now occurs to me that "fpi_data" should perhaps be called "block_fpi_data". What do you think? -- Peter Geoghegan