Great work, thank you very much! On Sun, Mar 24, 2019 at 6:02 AM Andres Freund <[email protected]> wrote: > Previously both delete/update/lock call-sites and the EPQ mechanism had > to have awareness of the specific tuple format to be able to fetch the > latest version of a tuple. Obviously that needs to be abstracted > away. To do so, move the logic that find the latest row version into > the AM. lock_tuple has a new flag argument, > TUPLE_LOCK_FLAG_FIND_LAST_VERSION, that forces it to lock the last > version, rather than the current one. It'd have been possible to do > so via a separate callback as well, but finding the last version > usually also necessitates locking the newest version, making it > sensible to combine the two. This replaces the previous use of > EvalPlanQualFetch(). Additionally HeapTupleUpdated, which previously > signaled either a concurrent update or delete, is now split into two, > to avoid callers needing AM specific knowledge to differentiate.
BTW, given your skepticism during PGCon 2018 discussions, I didn't expect my lock tuple patch [1] to get in. But if it finally got in, I've expected to be listed as author... 1. https://www.postgresql.org/message-id/CAJrrPGc951F-R4Kfa4W47B5vHKeHsB2Y34zewp%3Db%2BAWSkF9RVA%40mail.gmail.com ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
