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 1w6w4m-004nbT-35 for pgsql-docs@arkaria.postgresql.org; Sun, 29 Mar 2026 19:45:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w6w4k-00HBe5-2w for pgsql-docs@arkaria.postgresql.org; Sun, 29 Mar 2026 19:45:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w6w4k-00HBdw-2E for pgsql-docs@lists.postgresql.org; Sun, 29 Mar 2026 19:45:35 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w6w4j-00000001gpO-1TgW for pgsql-docs@lists.postgresql.org; Sun, 29 Mar 2026 19:45:34 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 62TJjVxQ1857027; Sun, 29 Mar 2026 15:45:31 -0400 From: Tom Lane To: Paul A Jungwirth cc: pgsql-docs@lists.postgresql.org Subject: Re: cmax docs seem misleading In-reply-to: References: Comments: In-reply-to Paul A Jungwirth message dated "Tue, 20 Jan 2026 10:46:01 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1857025.1774813531.1@sss.pgh.pa.us> Date: Sun, 29 Mar 2026 15:45:31 -0400 Message-ID: <1857026.1774813531@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Paul A Jungwirth writes: > The docs for cmax say:[0] >> The command identifier within the deleting transaction, or zero. > This was true once upon a time, I think. But nowadays cmax and cmin > are the same physical field, and the user-facing system columns don't > seem to be trying to interpret it. Yeah, this is a mess. Nobody ever updated this text when we decided we could pack those fields into one. I think it would be better to do what you suggest: > ... And maybe we should be more drastic: combine cmin & > cmax into one entry, and explain that they are two names for the same > value, which might signify the insert cid, the delete cid, or a > combocid. I'm not sure about good wording, but maybe like cmin, cmax: Originally, cmin and cmax were separate fields. cmin was the inserting command's command identifier within the inserting transaction, while cmax was the updating or deleting command's command identifier within the updating/deleting transaction, or zero if no update or delete attempt had occurred yet. Nowadays these system columns refer to the same field and will always read as the same value. That might be the inserting command's command identifier, or the deleting command's command identifier, or a "combocid" that reflects both actions when those happened in the same transaction. I don't know if we want to go into any more detail than that. regards, tom lane