Date: Wed, 24 Dec 2025 10:44:08 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Bernice Southey <bernice.southey@gmail.com>
Cc: pgsql-docs@lists.postgresql.org
Subject: Re: More guidance on ctid
Message-ID: <aUwKSGHaZAd5_xKl@momjian.us>
References: 
 <CAEDh4nyn5swFYuSfcnGAbpQrKOc47Hh_ZyKVSPYJcu2P=51Luw@mail.gmail.com>
 <aSTL3rgmztLq1UIH@momjian.us>
 <CAEDh4nzDMoRDZMDGGxKHzJ5hZscmvT2FWioTzQ6A0aJVtCO8NQ@mail.gmail.com>
 <aUnBfsbUbObEcY42@momjian.us>
 <CAEDh4nz-6HeVGHEU1Pv7Z4y=j44wtkeMyyJ5tfqAT5FHT4sq=w@mail.gmail.com>
 <aUsKZRmXgvI-k5Nb@momjian.us>
 <CAEDh4nwv22R3WBC-JW96YWfrvgA9UN=rDx11T4+zNrGVpXg5BQ@mail.gmail.com>
 <aUskW-srPCWXpi2R@momjian.us>
 <CAEDh4nyStja3R4X6qW_zpKz2w8EPUTsHQ8S0k9_saPA7BT+quw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAEDh4nyStja3R4X6qW_zpKz2w8EPUTsHQ8S0k9_saPA7BT+quw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aUwKSGHaZAd5_xKl%40momjian.us>
Precedence: bulk

On Wed, Dec 24, 2025 at 03:26:23PM +0000, Bernice Southey wrote:
> > Okay, let's give it another 12 hours and I will apply it tomorrow,
> > thanks.
> I had a new thought. Perhaps the root problem is trying to put too
> many things into one example. We can use the two examples to show
> different things.
> 
> I've kept batching - with skip lock, limit and ctid - in DELETE. Other
> than switching out skip lock for order by, this is much the same as
> currently, but with all the existing update explanatory text moved
> here. Skip lock makes ctid safe, and this is a good use of it.
> 
> I've used UPDATE to show how to prevent deadlocks with order by, for
> update, and an immutable key. This meant explaining why an immutable
> key matters, conveniently ruling out ctid without even mentioning it.
> 
> I think this now covers how to order by and limit with update and
> delete, how and why to batch, how to safely avoid deadlocks, how to
> use for update (with and without skip lock) and when and when not to
> use ctid.
> 
> But if you don't like this approach, I'm still happy if you go with
> your patch. I expect my patch needs quite a bit more work, even if you
> do like it.

We could go in the direction you suggested, but it seems out-of-place in
the UPDATE/DELETE docs since it gets into a lot of details.  Maybe in
the locking chapter?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.