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

From Tomas Vondra
Subject Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
Date
Msg-id a4adf3a3-7bab-f25d-2ddd-9d72cb548367@2ndquadrant.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  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: [HACKERS] [PATCH] pageinspect function to decode infomasks  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

On 08/15/2017 03:24 PM, Robert Haas wrote:
> On Mon, Aug 14, 2017 at 9:59 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> The bits are set, those macros just test to exclude the special meaning of
>> both bits being set at once to mean "frozen".
>>
>> I was reluctant to filter out  HEAP_XMIN_COMMITTED and HEAP_XMIN_INVALID
>> when we detect that it's frozen, because that could well be misleading when
>> debugging.
> 
> I don't think so -- the "committed" and "invalid" meanings are
> effectively canceled when the "frozen" mask is present.
> 
> I mean, "committed" and "invalid" contradict each other...
> 

FWIW I agree with Craig - the functions should output the masks raw, 
without any filtering. The reason is that when you're investigating data 
corruption or unexpected behavior, all this is very useful when 
reasoning about what might (not) have happened.

Or at least make the filtering optional.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] shared memory based stat collector (was: Sharing record typmods between backends)
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken