Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Sat, Sep 14, 2019 at 09:25:31AM +0530, Amit Kapila wrote:
> On Fri, Sep 13, 2019 at 5:31 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> A thought I had as I fell asleep last night is to include the derivate
>> flags in a separate output column altogether.  So
>> heap_tuple_infomask_flags() could be made to return two columns, one
>> with the straight one-flag-per-bit, and another one with the compound
>> flags.
>
> So, in most cases, the compound column will be empty, but in some
> cases like HEAP_XMIN_FROZEN, HEAP_XMAX_SHR_LOCK, etc. the flag will be
> displayed.  I like this idea though it will be a bit of noise in some
> cases but it is neat.  Another benefit is that one doesn't need to
> invoke this function twice to see the compound flags.

Hmmm.  Doesn't it become less user-friendly to invoke the function
then?  You would need to pass it down to the FROM clause after
fetching the raw page and then parsing its tuple items to have
t_infomask and t_infomask2 passed down as arguments to the new
function.  The one-column version has the advantage to be more
consistent with tuple_data_split() after getting all the values parsed
by heap_page_items().

>>  That way we always have the raw ones available, and we avoid any
>> confusion about strange cases such as LOCK_UPGRADED and IS_LOCKED_ONLY.
>
> Yeah, but I am not sure if we want to do display LOCK_UPGRADED stuff
> in the compound column as that is not directly comparable to other
> flags we want to display there like HEAP_XMIN_FROZEN,
> HEAP_XMAX_SHR_LOCK.

Yep, I agree that this one ought to not be considered as a proper
combination.  The other three ones are fine though.
--
Michael