On 08/15/2017 07:54 PM, Robert Haas wrote:
> On Tue, Aug 15, 2017 at 9:59 AM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>>> 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.
>
> 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 mean, if you were displaying the contents of a CLOG entry, would you
> want the value 3 to be displayed as COMMITTED ABORTED SUBCOMMITTED
> because TRANSACTION_STATUS_COMMITTED|TRANSACTION_STATUS_ABORTED ==
> TRANSACTION_STATUS_SUB_COMMITTED?
>
> I realize that you may be used to thinking of the HEAP_XMIN_COMMITTED
> and HEAP_XMAX_COMMITTED bits as two separate bits, but that's not
> really true any more. They're a 2-bit field that can have one of four
> values: committed, aborted, frozen, or none of the above.
>
All I'm saying is that having the complete information (knowing which
bits are actually set in the bitmask) is valuable when reasoning about
how you might have gotten to the current state. Which I think is what
Craig is after.
What I think we should not do is interpret the bitmasks (omitting some
of the information) assuming all the bits were set correctly.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
