Subject: Re: [PATCH] pageinspect function to decode infomasks
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: 
 <CAMsr+YEY7jeaXOb+oX+RhDyOFuTMdmHjGsBxL=igCm03J0go9Q@mail.gmail.com>
 <CAH2-Wzmdi6gr3FWtggKcSJZdt7Z1z75WbBCp4O8P6j5mfQSJLQ@mail.gmail.com>
 <CAOBaU_ac882pn-m+VisFHCycyZJmOZYz5pVh6c0VDxEPPK04fg@mail.gmail.com>
 <CAD21AoA3-H0C9Tek9CTBj0+QHiDQjG6ouw8Vep75prau8i9VhA@mail.gmail.com>
 <CAE9k0Pk8M+7CVs3f61wyfZLNR38qCYuPQE0ycvBYkBYKcTHaSg@mail.gmail.com>
 <CAMsr+YG-XXougF+voQRrtq24ZKUSD3GC3KVa429hSzJjOh=8KA@mail.gmail.com>
 <005801d31563$748c6560$5da53020$@lab.ntt.co.jp>
 <CAMsr+YGOMi+KgqU9ArkNmctS5crossszLL+pnxGGbuE2f-xWrg@mail.gmail.com>
 <CA+TgmoacQ+E9OFVQRJ2Pso=y2HgEE7W5u0oDSa3wyNmgKmQ1DA@mail.gmail.com>
 <a4adf3a3-7bab-f25d-2ddd-9d72cb548367@2ndquadrant.com>
 <CA+TgmoaAohvp8nFBe+9a-dcz9PuzObEfLDj3vNTkZ6na6aCpXg@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <bfc35546-9e1a-4827-9035-7e26ca95bbba@2ndquadrant.com>
Date: Tue, 15 Aug 2017 21:42:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
 <CA+TgmoaAohvp8nFBe+9a-dcz9PuzObEfLDj3vNTkZ6na6aCpXg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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


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