Hi, On 2023-01-09 19:59:42 -0800, Peter Geoghegan wrote: > On Mon, Jan 9, 2023 at 1:58 PM Andres Freund <and...@anarazel.de> wrote: > > A couple times when investigating data corruption issues, the last time just > > yesterday in [1], I needed to see the offsets affected by PRUNE and VACUUM > > records. As that's probably not just me, I think we should make that change > > in-tree. > > I remember how useful this was when we were investigating that early > bug in 14, that turned out to be in parallel VACUUM. So I'm all in > favor of it.
Cool. > > The attached patch adds details to XLOG_HEAP2_PRUNE, XLOG_HEAP2_VACUUM, > > XLOG_HEAP2_FREEZE_PAGE. > > I'm bound to end up doing the same in index access methods. Might make > sense for the utility routines to live somewhere more centralized, at > least when code reuse is likely. Practically every index AM has WAL > records that include a sorted page offset number array, just like > these ones. It's a very standard thing, obviously. Hm, there doesn't seem to be a great location for them today. I guess we could add something like src/include/access/rmgrdesc_utils.h? And put the implementation in src/backend/access/rmgrdesc/rmgrdesc_utils.c? I first was thinking of just rmgrdesc.[ch], but custom rmgrs added src/bin/pg_waldump/rmgrdesc.[ch] ... > > I chose to include infomask[2] for the different freeze plans mainly because > > it looks odd to see different plans without a visible reason. But I'm not > > sure > > that's the right choice. > > I don't think that it is particularly necessary to do so in order for > the output to make sense -- pg_waldump is inherently a tool for > experts. What it comes down to for me is whether or not this > information is sufficiently useful to display, and/or can be (or needs > to be) controlled via some kind of verbosity knob. It seemed useful enough to me, but I likely also stare more at this stuff than most. Compared to the list of offsets it's not that much content. > How hard would it be to invent a general mechanism to control the verbosity > of what we'll show for each WAL record? Nontrivial, I'm afraid. We don't pass any relevant parameters to rm_desc: void (*rm_desc) (StringInfo buf, XLogReaderState *record); so we'd need to patch all of them. That might be worth doing at some point, but I don't want to tackle it right now. Greetings, Andres Freund