Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> The one I was talking about is the second case, which prints
> KEYSHR_LOCK|EXCL_LOCK to mean that there's a FOR SHARE lock. I have no
> problem reading it this way, but I fear that someone unfamiliar with
> these bits might be confused. On the other hand, trying to be nice and
> interpret these bits (i.e. translate presence of both into something
> like SHR_LOCK) might also be confusing, because that bit doesn't really
> exist. And one already needs to be careful while interpreting what do
> KEYS_UPDATED and XMAX_LOCK_ONLY, or lack thereof, mean.
> Perhaps it would be sensible to provide one more output line per tuple,
> with interpretation of the flags, so it would tell you whether the tuple
> has been locked or updated, and what kind of each it is. I'd propose
> something like
> status: locked (FOR {KEY SHARE,SHARE,NO KEY UPDATE,UPDATE}) [MultiXact: nnn]
> status: [HOT] updated (KEYS UPDATED/KEYS NOT UPDATED) [MultiXact: nnn] To: blk/off
> status: deleted [MultiXact: nnn]
Hm. I'm loath to add another output line per tuple, just for space
reasons.
My feeling about this code is that the reason we print the infomask in
hex is so you can see exactly which bits are set if you care, and that
the rest of the line ought to be designed to interpret the bits in as
reader-friendly a way as possible. So I don't buy the notion that we
should just print out a name for each bit that's set. I'd rather
replace individual bit names with items like LOCKED_FOR_KEY_SHARE,
LOCKED_FOR_SHARE, etc in cases where you have to combine multiple
bits to understand the meaning.
regards, tom lane
