On Thu, Mar 02, 2023 at 11:17:05AM -0500, Melanie Plageman wrote: > Thinking about this more, it could make sense to have a function which > gives you this extended block information and has a parameter like > with_fpi which would include the information returned by > pg_get_wal_fpi_info(). It might be nice to have it still include the > information about the record itself as well.
Hmm. I am OK if you want to include more information about the blocks, and it may be nicer to not bloat the interface with more functions than necessary. > I don't know if it would be instead of pg_get_wal_fpi_info(), though. > > The way I would use this is when I want to see the record level > information but with some additional information aggregated across the > relevant blocks. For example, I could group by the record information > and relfilenode and using the query in my example above, see all the > information for the record along with the relname (when possible). As far as I know, a block reference could have some data or a FPW, so it is true that pg_get_wal_fpi_info() is not extensive enough if you want to get more information about the blocks in use for each record, especially if there is some data, and grouping the information about whole set of blocks into a single function call can some time. In order to satisfy your case, why not having one function that does everything, looping over the blocks of a single record as long as XLogRecHasBlockRef() is satisfied, returning the FPW if the block includes an image (or NULL if !XLogRecHasBlockImage()), as well as its data in bytea if XLogRecGetData() gives something (?). I am not sure that this should return anything about the record itself except its ReadRecPtr, though, as ReadRecPtr would be enough to cross-check with the information provided by GetWALRecordInfo() with a join. Hence, I guess that we could update the existing FPI function with: - the addition of some of the flags of bimg_info, like the compression type, if they apply, with a text[]. - the addition of bimg_len, if the block has a FPW, or NULL if none. - the addition of apply_image, if the block has a FPW, or NULL if none. - the addition of the block data, if any, or NULL if there is no data. - an update for the FPW handling, where we would return NULL if there is no FPW references in the block, but still return the full, decompressed 8kB image if it is there. -- Michael
signature.asc
Description: PGP signature