public inbox for [email protected]  
help / color / mirror / Atom feed
From: Subramanian,Ramachandran <[email protected]>
To: David G. Johnston <[email protected]>
Cc: [email protected] <[email protected]>
Subject: AW: Trying to understand Tuple Header
Date: Mon, 4 May 2026 04:04:30 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwbRKbjk4JPefgT6s64hN-i47a1nZO6O4j-+h48er6uyvw@mail.gmail.com>
References: <[email protected]>
	<CAKFQuwawOYYR=Dfa3tWsKOd-baJ-hV7SKMj9FHiMnd9f-=vNAg@mail.gmail.com>
	<[email protected]>
	<CAKFQuwbRKbjk4JPefgT6s64hN-i47a1nZO6O4j-+h48er6uyvw@mail.gmail.com>

Wow!!!  Thank you.  You are correct. T_infomask did change.

I began with postgres in Nov 2025 and I am having so much fun learning it. I am deeply grateful for this community.


So the next select to the table cross references the pg_xact file to check if hint bits need to be updated or not ?  How deep does the next select look into the pg_xact file ? For example if I roll back and never touch this table for 30  Minutes and I come back and do a second select…will it look back into 30 mins of history in pg_xact ?


It is a wonderful morning to have learned a little bit of PG Magic 😊 .  Thank you all.





SELECT t_ctid,t_infomask, cast(t_infomask as bit(16))  FROM heap_page_items(get_raw_page('One_Page_Wonder',0));
t_ctid | t_infomask |    t_infomask
--------+------------+------------------
(0,1)  |       2050 | 0000100000000010
(0,2)  |       2050 | 0000100000000010
(2 rows)

SELECT * FROM One_Page_Wonder ;
id |        text        |         time_stamp
----+--------------------+----------------------------
  1 | First row Inserted | 2026-05-04 05:50:32.540905
(1 row)

SELECT t_ctid,t_infomask, cast(t_infomask as bit(16))  FROM heap_page_items(get_raw_page('One_Page_Wonder',0));
t_ctid | t_infomask |    t_infomask
--------+------------+------------------
(0,1)  |       2306 | 0000100100000010
(0,2)  |       2562 | 0000101000000010
(2 rows)



Freundliche Grüße

i. A. Ramachandran Subramanian
Zentralbereich Informationstechnologie

Alte Leipziger Lebensversicherung a.G.


Hallesche Krankenversicherung a.G.







Alte Leipziger Lebensversicherung a.G., Alte Leipziger-Platz 1, 61440 Oberursel
Vors. des Aufsichtsrats: Dr. Walter Botermann · Vorstand: Christoph Bohn (Vors.), Dr. Jürgen Bierbaum (stv. Vors.), Frank Kettnaker, Dr. Jochen Kriegmeier, Alexander Mayer, Christian Pape, Wiltrud Pekarek, Udo Wilcsek
Sitz Oberursel (Taunus) · Rechtsform VVaG · Amtsgericht Bad Homburg v. d. H. HRB 1583 · USt.-IdNr. DE 114106814





 
Hallesche Krankenversicherung a.G.,  Löffelstraße 34-38, 70597 Stuttgart
Vors. des Aufsichtsrats: Dr. Walter Botermann · Vorstand: Christoph Bohn (Vors.), Dr. Jürgen Bierbaum (stv. Vors.), Frank Kettnaker, Dr. Jochen Kriegmeier, Alexander Mayer, Christian Pape,
Wiltrud Pekarek, Udo Wilcsek
Sitz Stuttgart · Rechtsform VVaG · Amtsgericht Stuttgart HRB 2686 · USt.-IdNr. DE 147802285
Beiträge zu privaten Kranken- und Pflegekrankenversicherungen unterliegen nicht der Versicherungsteuer (§ 4 Nr. 5 VersStG) · Versicherungsleistungen sowie Umsätze aus Versicherungsvertreter-/Maklertätigkeiten sind umsatzsteuerfrei
 



 
Die Pflichtangaben der ALH Gruppe gemäß § 35a GmbHG bzw. § 80 AktG finden Sie hier: https://www.alte-leipziger.de/impressum 





______________________

ALH Gruppe
Alte Leipziger-Platz 1, 61440 Oberursel
Tel.: +49 (6171) 66-4882
Fax: +49 (6171) 66-800-4882
E-Mail: [email protected]
www.alte-leipziger.de
www.hallesche.de




Von: David G. Johnston <[email protected]>
Gesendet: Sonntag, 3. Mai 2026 21:49
An: Subramanian,Ramachandran IT-md-db <[email protected]>
Cc: [email protected]
Betreff: Re: Trying to understand Tuple Header

On Sun, May 3, 2026 at 12:25 PM Subramanian,Ramachandran <[email protected]<mailto:[email protected]>> wrote:
The binary value of t_infomask for both the tuples are identical, but they produce different column values for xmin_commited, xmin_aborted ….  in the SQL  !!!.

Am I not seeing something that is obvious?

You didn't re-check the infomask data after running the select query, instead assuming the bits didn't change.  They did.  SELECT is not a read-only operation, it participates in optimizations.  Called "writing hint bits".  Manually evaluating the various tests against the data you did show would have proven that the pre-select-data had zeros where the second query claims there are ones.

David J.



reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: AW: Trying to understand Tuple Header
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox