Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
От | Alvaro Herrera |
---|---|
Тема | Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination |
Дата | |
Msg-id | 20210204162235.GA18329@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
|
Список | pgsql-hackers |
On 2021-Feb-05, Julien Rouhaud wrote: > - HEAP_KEYS_UPDATED > This bit lives in t_infomask2. If set, indicates that the XMAX updated > - this tuple and changed the key values, or it deleted the tuple. > - It's set regardless of whether the XMAX is a TransactionId or a MultiXactId. > + this tuple and changed the key values, or it deleted the tuple. It can also > + be set in combination of HEAP_XMAX_LOCK_ONLY. It's set regardless of whether > + the XMAX is a TransactionId or a MultiXactId. I think we should reword this more completely, to avoid saying one thing (that the op is an update or delete) and then contradicting ourselves (that it can also be a lock). I propose this: This bit lives in t_infomask2. If set, it indicates that the operation(s) done by the XMAX compromise the tuple key, such as a SELECT FOR UPDATE, an UPDATE that modifies the columns of the key, or a DELETE. Also, I just noticed that the paragraph just above this one says that HEAP_XMAX_EXCL_LOCK is used for both SELECT FOR UPDATE and SELECT FOR NO KEY UPDATE, and that this bit is what differentiates them. -- Álvaro Herrera Valdivia, Chile "Oh, great altar of passive entertainment, bestow upon me thy discordant images at such speed as to render linear thought impossible" (Calvin a la TV)
В списке pgsql-hackers по дате отправления: