Re: [HACKERS] [PATCH] pageinspect function to decode infomasks - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
Date
Msg-id CAH2-WzmCaonV96U9CvhSfWYTm9Gma-WYCMY3G=jg0zkVdxxoFg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] pageinspect function to decode infomasks  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
List pgsql-hackers
On Fri, Oct 13, 2017 at 1:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I don't think it's our place to "interpret" the bits. Are we *also*
>> going to show HEAP_XMIN_FROZEN when xmin is physically set to
>> FrozenTransactionId?
>
> No, of course not.  We're talking about how to display the 256 and 512
> bits of t_infomask.  Those have four states: nothing, committed,
> invalid, frozen.  You're arguing that frozen isn't a real state, that
> it's somehow just a combination of committed and invalid, but I think
> that's the wrong way of thinking about it.

No, I'm arguing that they're just bits. Show the bits, rather than
interpreting what is displayed. Document that there are other logical
states that are represented as composites of contradictory/mutually
exclusive states.

Anyone who hopes to interpret these values has to be an expert anyway,
or willing to become something of an expert. There is a good chance
that they've taken an interest because something is already wrong.

> Before HEAP_XMIN_FROZEN existed, it would have been right to display
> the state where both bits are set as committed|invalid, because that
> would clearly show you that two things had been set that should never
> both be set at the same time.  But now that's a valid state with a
> well-defined meaning and I think we should display the actual meaning
> of that state.
>
>> Where does it end?
>
> I guess it ends wherever we decide to stop.

You can take what you're saying much further. What about
HEAP_XMAX_SHR_LOCK, and HEAP_MOVED? Code like HEAP_LOCKED_UPGRADED()
pretty strongly undermines the idea that these composite values are
abstractions.

>> I think that we should prominently document that HEAP_XMIN_COMMITTED
>> |HEAP_XMIN_ABORTED == HEAP_XMIN_FROZEN, rather than trying to hide
>> complexity that we have no business hiding in a tool like pageinspect.
>
> I respect that opinion, but I don't think I'm trying to hide anything.
> I think I'm proposing that we display the information in what I
> believed to be the clearest and most accurate way.

pg_filedump doesn't display HEAP_XMIN_FROZEN, either. (Nor does it
ever display any of the other composite t_infomask/t_infomask2
values.)

-- 
Peter Geoghegan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Gourav Kumar
Date:
Subject: Re: [HACKERS] Disable cross products in postgres
Next
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] Extended statistics is not working on Vars hidden undera RelabelType