Horton

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

Aleksander Alekseev <aleksander@timescale.com>

View thread View on postgr.es
From: Aleksander Alekseev <aleksander@timescale.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Mason Sharp <masonlists@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, vignesh C <vignesh21@gmail.com>
Date: 2023-01-09T09:56:12Z
Lists: pgsql-hackers

Attachments

Hi Alexander,

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

```
@@ -318,12 +318,12 @@ heapam_tuple_delete(Relation relation,
ItemPointer tid, CommandId cid,
     result = heap_delete(relation, tid, cid, crosscheck, wait, tmfd,
changingPart);

     /*
-     * If the tuple has been concurrently updated, get lock already so that on
-     * retry it will succeed, provided that the caller asked to do this by
-     * providing a lockedSlot.
+     * If lockUpdated is true and the tuple has been concurrently updated, get
+     * the lock immediately so that on retry we will succeed.
      */
     if (result == TM_Updated && lockUpdated)
     {
+        Assert(lockedSlot != NULL);
```

... and the same for heapam_tuple_update().

-- 
Best regards,
Aleksander Alekseev

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.