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-Wz==wy_hssq1gLh-ryMf5dYE3KdLBhc+jZGzmbzWk4wUzQ@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 Tue, Aug 15, 2017 at 10:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Or at least make the filtering optional.
>
> I don't think "filtering" is the right way to think about it.  It's
> just labeling each combination of bits with the meaning appropriate to
> that combination of bits.

I do. -1 to not just showing what's on the page -- if the
HEAP_XMIN_COMMITTED and HEAP_XMIN_ABORTED bits are set, then I think
we should show them. Yeah, I accept that there is a real danger of
confusing people with that. Unfortunately, I think that displaying
HEAP_XMIN_FROZEN will cause even more confusion. I don't think that
HEAP_XMIN_FROZEN is an abstraction at all. It's a notational
convenience.

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? Where does it end?

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.

-- 
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: Alvaro Herrera
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Fix traversal of half-frozen update chains
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions