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 1vYVWs-005SEw-0C for pgsql-docs@arkaria.postgresql.org; Wed, 24 Dec 2025 20:32:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vYVWq-005c8S-1r for pgsql-docs@arkaria.postgresql.org; Wed, 24 Dec 2025 20:32:17 +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 1vYVWq-005c8K-13 for pgsql-docs@lists.postgresql.org; Wed, 24 Dec 2025 20:32:17 +0000 Received: from mail-yw1-x1132.google.com ([2607:f8b0:4864:20::1132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vYVWn-002Zee-0X for pgsql-docs@lists.postgresql.org; Wed, 24 Dec 2025 20:32:15 +0000 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-78fc4425b6bso32892077b3.1 for ; Wed, 24 Dec 2025 12:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766608331; x=1767213131; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+UnaC0pcJPZ9NOv7dcCPZ8zcc/zLmoHAadua+z6OFz4=; b=El4LuCcGZ8+WVnkbtlZZjYjaDDWt1bGkh7DhvfCpWC9GwfeMl0ccUU6keZxUW4ADac uO0KYi/XyLd26ATwx2C+xLrtFdyT/V2EQ3LNAWo+TyvXT49Y8r4jzqjYKbwFVUGR4K3C O47ICoyFpSQp7K78VGXx5b5IQQ11hUyw1FaYpkJLRieKrIhkovM45z/bQwjpxmG9Ouch AYMchfoI0h/mYrSrokaJ2VmMJnJs2yrsu7+CiftVdHKjer+xcrH9PuZupJXz7iU+AkrH SGDKh/71O2k7v6d2HL/ZEyAx96AUZb4YcSAhOEYwEzce5tyUzBTNJzqRt8ieX7f4HUMO x/Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766608331; x=1767213131; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+UnaC0pcJPZ9NOv7dcCPZ8zcc/zLmoHAadua+z6OFz4=; b=gZJkPKyLaSohUvqBqycYXm1WSpsAtB7DialmKxQr2BoyuR6J5DKhy32Hb3tSjY1O1B iBCp5MFGdHgr4VBvZK0hG9qxHqmYhc2aecVItr3anpBf5qZAj7BLHZzkk8Z9eMNcmVoI fuMJJRUl2IFO5N9SlB7zPcyzSym1/w5nNSqxbHs6MLrtBpGVpRlgPUUO2h2aRjLpSOlq OVHhkbp3/gfIA/SU+Ee46Ep1yQQnsWUlLpf4tRHcpniMbvTC5hath8T+zwNYoIhaVard BmgLka9pm4EC/jh1WRx9B0FBTRFvhImdH+eIqIuWcbrfmvmlP9necYS5rg+aftug6AZW jJdg== X-Gm-Message-State: AOJu0YydUh+tBfeH/NenWz9rSBcMD0DQrdrsN6w2z5hRD+u/oGY0nK42 zpoEzIIQnFk97ZWiQVoCzKfVBzFrp4mYSNcYpxx7/IxvM2sIdIk1v9m9ScevnaO+n7EgU2rAZbd T5W1AzV7jCZ9WV56CkMUHaih3dtdqyr4= X-Gm-Gg: AY/fxX5Admq4i66jt5juWRaglgEzGSNAaSBDTYtj/jCjTTy/zHGxAJGSh1MA2ExCrhq aZiJEzZl3QEQHCJRrgYZS7oN4Lg4rpOfdjMezQcOJTVyrhBmV2V+XrY5DbGpDUfsCxP5uiMz1eK mTlPa7JvIEONaNuvA28hEqjo/AuiIY3L++J0+d+1PdslkrE1JHu/cyw2IXd11gQYZSffgnMuE8d KmC7ZiXhivmH4Wq5xp6dKxW6THaZnqFgtbc4Te6KqAfCDk5LMusNRxNZAfynuByX4Aa9QsNwBl/ XrmhSVlGZluMDcfsiSfT X-Google-Smtp-Source: AGHT+IGlIONoYSUYc8CkpEauP8Llp9ZieojUP0CJ6P3jaSmQmTIyKJb+VbYDnWGMnBH3LNZiAci4ouywgVMFC+py3Hc= X-Received: by 2002:a05:690c:9a0a:b0:786:6b92:b201 with SMTP id 00721157ae682-78fb4026a4fmr152503287b3.13.1766608331341; Wed, 24 Dec 2025 12:32:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bernice Southey Date: Wed, 24 Dec 2025 20:31:35 +0000 X-Gm-Features: AQt7F2rnrX_AIOH8EWqz32zLg1UNPNnoqZD9urvk3wCcA0TqRH3fXfgRLYYsNvs Message-ID: Subject: Re: More guidance on ctid To: Bruce Momjian Cc: pgsql-docs@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Bruce Momjian wrote: > I am not the author of the original ctid doc patch, but I believe the > goal was to use ctid so we don't need to use needless index lookups for > primary keys. Yes, you are right, this was one of the goals. The other initial goals were to stop people complaining about no order by and limit, and to encourage batching. Avoiding deadlocks was very much discussed, but not listed as one of the primary initial goals by the patch writer, if memory serves. I was just thinking I prefer keeping ctid in lock free examples with your new warning. ctid is safe without concurrency and for batching to completion. There's an argument for moving the deadlock stuff into the locking chapter because as soon as one does a select and then an update in a concurrent world, one is guaranteed to lose rows with ctid or any mutable key. If you think I'm overly concerned, and the examples are fine with the locking and ctid and a warning, I concede. The locking chapter does have good guidance on ordering already.