Great work, thank you very much!
On Sun, Mar 24, 2019 at 6:02 AM Andres Freund <andres@anarazel.de> 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