public inbox for pgsql-novice@postgresql.org
help / color / mirror / Atom feedAW: Trying to understand Tuple Header
2+ messages / 2 participants
[nested] [flat]
* AW: Trying to understand Tuple Header
@ 2026-05-04 04:04 Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de>
2026-05-04 07:32 ` Re: AW: Trying to understand Tuple Header Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 2+ messages in thread
From: Subramanian,Ramachandran @ 2026-05-04 04:04 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: pgsql-novice@lists.postgresql.org <pgsql-novice@lists.postgresql.org>
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: 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:49
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 Sun, May 3, 2026 at 12:25 PM Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de<mailto:ramachandran.subramanian@alte-leipziger.de>> 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.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: AW: Trying to understand Tuple Header
2026-05-04 04:04 AW: Trying to understand Tuple Header Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de>
@ 2026-05-04 07:32 ` Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 0 replies; 2+ messages in thread
From: Laurenz Albe @ 2026-05-04 07:32 UTC (permalink / raw)
To: Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de>; David G. Johnston <david.g.johnston@gmail.com>; +Cc: pgsql-novice@lists.postgresql.org <pgsql-novice@lists.postgresql.org>
On Mon, 2026-05-04 at 04:04 +0000, Subramanian,Ramachandran wrote:
> 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 ?
Yes. It has to, to maintain correctness.
If nobody ever looks at the row, eventually autovacuum will freeze it. Any pg_xact
segment that only contains transactions older than the oldest unfrozen row will
get reclaimed.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-05-04 07:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-05-04 04:04 AW: Trying to understand Tuple Header Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de>
2026-05-04 07:32 ` Laurenz Albe <laurenz.albe@cybertec.at>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox