AW: Trying to understand Tuple Header

Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de>

From: "Subramanian,Ramachandran" <ramachandran.subramanian@alte-leipziger.de>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: "pgsql-novice@lists.postgresql.org" <pgsql-novice@lists.postgresql.org>
Date: 2026-05-03T19:25:14Z
Lists: pgsql-novice
Thank you so much for your speedy reply.


I Googled and found Egor Rogov’s SQL.

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?


Regards

Ram







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

SELECT * FROM One_Page_Wonder ;
id |        text        |         time_stamp
----+--------------------+----------------------------
  1 | First row Inserted | 2026-05-03 21:18:24.631047
(1 row)

SELECT '(0,'||lp||')' AS ctid,
       CASE lp_flags
         WHEN 0 THEN 'unused'
         WHEN 1 THEN 'normal'
         WHEN 2 THEN 'redirect to '||lp_off
         WHEN 3 THEN 'dead'
       END AS state,
       t_xmin as xmin,
       t_xmax as xmax,
       (t_infomask & 256) > 0  AS xmin_commited,
       (t_infomask & 512) > 0  AS xmin_aborted,
       (t_infomask & 1024) > 0 AS xmax_commited,
       (t_infomask & 2048) > 0 AS xmax_aborted,
       t_ctid
FROM heap_page_items(get_raw_page('One_Page_wonder',0));
ctid  | state  | xmin | xmax | xmin_commited | xmin_aborted | xmax_commited | xmax_aborted | t_ctid
-------+--------+------+------+---------------+--------------+---------------+--------------+--------
(0,1) | normal | 3673 |    0 | t             | f            | f             | t            | (0,1)
(0,2) | normal | 3674 |    0 | f             | t            | f             | t            | (0,2)
(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: ramachandran.subramanian@alte-leipziger.de
www.alte-leipziger.de
www.hallesche.de




Von: David G. Johnston <david.g.johnston@gmail.com>
Gesendet: Sonntag, 3. Mai 2026 21:03
An: Subramanian,Ramachandran IT-md-db <ramachandran.subramanian@alte-leipziger.de>
Cc: pgsql-novice@lists.postgresql.org
Betreff: Re: Trying to understand Tuple Header

On Sunday, May 3, 2026, Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de<mailto:ramachandran.subramanian@alte-leipziger.de>> wrote:
How does postgres know that this 4th tuple has been rolled back ?  Please help me learn that.

The pg_xact file holds information pertaining to whether a transaction produced live or dead tuples upon ending.

David J.