Horton

Re: POC: Lock updated tuples in tuple_update() and tuple_delete()

Alexander Korotkov <aekorotkov@gmail.com>

View thread View on postgr.es
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Chris Travers <chris.travers@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-03-27T10:49:22Z
Lists: pgsql-hackers 
Hi!

On Fri, Mar 24, 2023 at 3:39 AM Andres Freund <andres@anarazel.de> wrote:
> On 2023-03-23 23:24:19 +0300, Alexander Korotkov wrote:
> > On Thu, Mar 23, 2023 at 8:06 PM Andres Freund <andres@anarazel.de> wrote:
> > > I seriously doubt that solving this at the tuple locking level is the right
> > > thing. If we want to avoid refetching tuples, why don't we add a parameter to
> > > delete/update to generally put the old tuple version into a slot, not just as
> > > an optimization for a subsequent lock_tuple()? Then we could remove all
> > > refetching tuples for triggers. It'd also provide the basis for adding support
> > > for referencing the OLD version in RETURNING, which'd be quite powerful.

After some thoughts, I think I like idea of fetching old tuple version
in update/delete.  Everything that evades extra tuple fetching and do
more of related work in a single table AM call, makes table AM API
more flexible.

I'm working on patch implementing this.  I'm going to post it later today.

------
Regards,
Alexander Korotkov

Commits

  1. Add EvalPlanQual delete returning isolation test

  2. Allow locking updated tuples in tuple_update() and tuple_delete()

  3. Revert 764da7710b

  4. Revert 11470f544e

  5. Evade extra table_tuple_fetch_row_version() in ExecUpdate()/ExecDelete()

  6. Check that xmax didn't commit in freeze check.