Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Chris Travers <chris.travers@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-04-02T00:47:18Z
Lists: pgsql-hackers
Hi, On 2023-04-02 03:37:19 +0300, Alexander Korotkov wrote: > On Sat, Apr 1, 2023 at 8:21 AM Andres Freund <andres@anarazel.de> wrote: > > Given that the in-tree state has been broken for a week, I think it probably > > is time to revert the commits that already went in. > > The revised patch is attached. The most notable change is getting rid > of LazyTupleTableSlot. Also get rid of complex computations to detect > how to initialize LazyTupleTableSlot. Instead just pass the oldSlot > as an argument of ExecUpdate() and ExecDelete(). The price for this > is just preallocation of ri_oldTupleSlot before calling ExecDelete(). > The slot allocation is quite cheap. After all wrappers it's > table_slot_callbacks(), which is very cheap, single palloc() and few > fields initialization. It doesn't seem reasonable to introduce an > infrastructure to evade this. > > I think patch resolves all the major issues you've highlighted. Even > if there are some minor things missed, I'd prefer to push this rather > than reverting the whole work. Shrug. You're designing new APIs, days before the feature freeze. This just doesn't seem ready in time for 16. I certainly won't have time to look at it sufficiently in the next 5 days. Greetings, Andres Freund
Commits
-
Add EvalPlanQual delete returning isolation test
- 8ffc2aa720a2 17.0 landed
-
Allow locking updated tuples in tuple_update() and tuple_delete()
- 87985cc92522 17.0 landed
- 11470f544e37 16.0 landed
-
Revert 764da7710b
- b0b91ced167f 16.0 landed
-
Revert 11470f544e
- 2b65bf046d8a 16.0 landed
-
Evade extra table_tuple_fetch_row_version() in ExecUpdate()/ExecDelete()
- 764da7710bf6 16.0 landed
-
Check that xmax didn't commit in freeze check.
- eb5ad4ff05fd 16.0 cited