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

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>
To: Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Mason Sharp <masonlists@gmail.com>, vignesh C <vignesh21@gmail.com>
Date: 2023-01-09T10:46:50Z
Lists: pgsql-hackers
Hi, Pavel!

On Mon, Jan 9, 2023 at 1:41 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> On Mon, 9 Jan 2023 at 13:29, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > On Mon, Jan 9, 2023 at 1:10 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > > On Mon, Jan 9, 2023 at 12:56 PM Aleksander Alekseev
> > > <aleksander@timescale.com> wrote:
> > > > > I'm going to push this if no objections.
> > > >
> > > > I took a fresh look at the patch and it LGTM. I only did a few
> > > > cosmetic changes, PFA v7.
> > > >
> > > > Changes since v6 are:
> > >
> > > Thank you for looking into this.  It appears that I've applied changes
> > > proposed by Mason to v5, not v6.  That lead to comment mismatch with
> > > the code that you've noticed.  v8 should be correct.  Please, recheck.
> >
> > v9 also incorporates lost changes to the commit message by Pavel Borisov.
> I've looked through patch v9. It resembles patch v5 plus comments
> clarification by Mason plus the right discussion link in the commit
> message from v8. Aleksander's proposal of Assert in v7 was due to
> changes lost between v5 and v6, as combining connected variables in v5
> makes checks for them being in agreement one with the other
> unnecessary. So changes from v7 are not in v9.
>
> Sorry for being so detailed in small details. In my opinion the patch
> now is ready to be committed.

Sorry for creating this mess with lost changes.  And thank you for
confirming it's good now.  I'm going to push v9.

------
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.