Hi, Mason! Thank you very much for your review.
On Sun, Jan 8, 2023 at 9:33 PM Mason Sharp <masonli...@gmail.com> wrote: > On Fri, Jan 6, 2023 at 4:46 AM Pavel Borisov <pashkin.e...@gmail.com> wrote: >> Besides, the new version has only some minor changes in the comments >> and the commit message. > It looks good, and the greater the concurrency the greater the benefit will > be. Just a few minor suggestions regarding comments. > > "ExecDeleteAct() have already locked the old tuple for us", change "have" to > "has". > > The comments in heapam_tuple_delete() and heapam_tuple_update() might be a > little clearer with something like: > > "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." Thank you. These changes are incorporated into v6 of the patch. > Also, not too important, but perhaps better clarify in the commit message > that the repeated work is driven by ExecUpdate and ExecDelete and can happen > multiple times depending on the concurrency. Hmm... It can't happen arbitrary number of times. If tuple was concurrently updated, the we lock it. Once we lock, nobody can change it until we finish out work. So, I think no changes needed. I'm going to push this if no objections. ------ Regards, Alexander Korotkov
0001-Allow-locking-updated-tuples-in-tuple_update-and--v6.patch
Description: Binary data
