Re: pgsql: tableam: Add tuple_{insert, delete, update, lock} and use.
От | Alexander Korotkov |
---|---|
Тема | Re: pgsql: tableam: Add tuple_{insert, delete, update, lock} and use. |
Дата | |
Msg-id | CAPpHfdsEi8DuUyy=aC=CenmD0H1Azx_vvytDzNQU6XHOWthM3A@mail.gmail.com обсуждение исходный текст |
Ответ на | pgsql: tableam: Add tuple_{insert, delete, update, lock} and use. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: pgsql: tableam: Add tuple_{insert, delete, update, lock} and use.
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: