Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wJfe3-0007bO-2j for pgsql-novice@arkaria.postgresql.org; Sun, 03 May 2026 22:50:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wJfe2-004xs5-28 for pgsql-novice@arkaria.postgresql.org; Sun, 03 May 2026 22:50:38 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wJfe2-004xrx-1M for pgsql-novice@lists.postgresql.org; Sun, 03 May 2026 22:50:38 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wJfe0-00000000LtT-0RNC for pgsql-novice@lists.postgresql.org; Sun, 03 May 2026 22:50:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 643MoNgq097768; Sun, 3 May 2026 18:50:23 -0400 From: Tom Lane To: "David G. Johnston" cc: "Subramanian, Ramachandran" , "pgsql-novice@lists.postgresql.org" Subject: Re: Trying to understand Tuple Header In-reply-to: References: <0f8e5544ae8a412bb637fcc3d15f8aaa@alte-leipziger.de> Comments: In-reply-to "David G. Johnston" message dated "Sun, 03 May 2026 12:48:47 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <97766.1777848623.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 03 May 2026 18:50:23 -0400 Message-ID: <97767.1777848623@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Sun, May 3, 2026 at 12:25=E2=80=AFPM Subramanian,Ramachandran < > ramachandran.subramanian@alte-leipziger.de> wrote: >> The binary value of t_infomask for both the tuples are identical, but t= hey >> produce different column values for xmin_commited, xmin_aborted =E2=80=A6= . in the >> SQL !!!. > 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". Well, it *might* update the hint bits, but it can only do that after the tuple is visible to all live transactions. So it matters what else is happening within the database. In any case, pg_xact is the ultimate source of truth about whether a tuple is committed or not. regards, tom lane