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 1vXo5U-006Bfe-1z for pgsql-docs@arkaria.postgresql.org; Mon, 22 Dec 2025 22:09:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vXo5T-00GMVg-1f for pgsql-docs@arkaria.postgresql.org; Mon, 22 Dec 2025 22:09:08 +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 1vXo5T-00GMVY-0n for pgsql-docs@lists.postgresql.org; Mon, 22 Dec 2025 22:09:08 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vXo5R-002BdR-0M for pgsql-docs@lists.postgresql.org; Mon, 22 Dec 2025 22:09:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2025010100; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=098K6saQ+4Eb1rhMTvujz4zX3LD9yYFRFkSmcAKigfU=; b=VlGLz /rRuBNwcoSW9XDz6cViG9KWOlWFqnyswnzNbIVAfVVbDXW9xc41V8EYoG+i6pzH63P2FI4BcRdeT3 F1ndSJiuGCenNL3WZk6EDdkGhNhcoukIo4a7iSf3135ZJ4783v7ZWJJ1CRoFzUEIPeDDdctq89f4T 2E4YLt3IelF8DrTfX/qLnThTH2soRKnEO7AapOjTlL9In35zWuJAgxyq74CgeXe/srsUjDs/Izozz YnSUukxPoK2C3L88zD0d5KMwW3ZlQ/Wb60nAFICEJjoe97QfVXDAdmOaJrP8R4GIN6dgY53xsGBUj ygeV7/tCaiALoi4WqEGIcbpAIIykA==; Received: from bruce by momjian.us with local (Exim 4.98.2) (envelope-from ) id 1vXo5O-0000000EEpp-2Byd; Mon, 22 Dec 2025 17:09:02 -0500 Date: Mon, 22 Dec 2025 17:09:02 -0500 From: Bruce Momjian To: Bernice Southey Cc: pgsql-docs@lists.postgresql.org Subject: Re: More guidance on ctid Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2sC7vwC7qNHoANmw" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --2sC7vwC7qNHoANmw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Nov 29, 2025 at 10:45:45PM +0000, Bernice Southey wrote: > Bruce Momjian wrote: > This is why I think the docs should say something different to what > they currently do. The UPDATE example is fine only because it's run > repeatedly until there are no more rows to find. > > I learned the primary key self-join pattern for order by/limit in > delete/update soon after I began with postgres. I'm pretty sure ctid > would have confused me. So I think the doc examples with an id column > will be very helpful, and safer. > > If users discover ctid on internet forums or LLMs and then check the > docs, I think they should get some notice of the concurrency risk. > > Here's a patch with an attempt to do the above. I was traveling so I apologize for the delayed reply. Sorry, I didn't like your proposed patch because it removes the ctid example, and I didn't write that example so I don't feel enabled to remove it. What I did do was to explain why ctid was safe in this use-case. I also strengthened the documentation that ctid is not valid for row references. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future. --2sC7vwC7qNHoANmw Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ctid.diff" diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index cea28c00f8a..9070aaa5a7c 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1558,7 +1558,7 @@ CREATE TABLE circles ( locate the row version very quickly, a row's ctid will change if it is updated or moved by VACUUM FULL. Therefore - ctid is useless as a long-term row + ctid should not be used as a row identifier. A primary key should be used to identify logical rows. diff --git a/doc/src/sgml/ref/delete.sgml b/doc/src/sgml/ref/delete.sgml index 5b52f77e28f..c8dce945b06 100644 --- a/doc/src/sgml/ref/delete.sgml +++ b/doc/src/sgml/ref/delete.sgml @@ -323,6 +323,9 @@ DELETE FROM user_logs AS dl USING delete_batch AS del WHERE dl.ctid = del.ctid; + This use of ctid is only safe because + the query is repeately run, avoiding the problem of changed + ctids. diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml index 40cca063946..289f48b2549 100644 --- a/doc/src/sgml/ref/update.sgml +++ b/doc/src/sgml/ref/update.sgml @@ -503,6 +503,9 @@ UPDATE work_item SET status = 'failed' WHERE work_item.ctid = emr.ctid; This command will need to be repeated until no rows remain to be updated. + (This use of ctid is only safe because + the query is repeately run, avoiding the problem of changed + ctids.) Use of an ORDER BY clause allows the command to prioritize which rows will be updated; it can also prevent deadlock with other update operations if they use the same ordering. --2sC7vwC7qNHoANmw--