Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
| От | Julien Rouhaud |
|---|---|
| Тема | Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination |
| Дата | |
| Msg-id | 20210204163750.GB22612@nol обсуждение исходный текст |
| Ответ на | Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Ответы |
Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
|
| Список | pgsql-hackers |
On Thu, Feb 04, 2021 at 01:22:35PM -0300, Alvaro Herrera wrote: > 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. Thanks, that's way better, copied in v3. I'm still a bit worried about that description though, as that flag isn't consistently set for the FOR UPDATE case. Well, to be more precise it's maybe consistently set when the hint bits are computed, but in some cases the flag is later cleared, so you won't reliably find it in the tuple.
Вложения
В списке pgsql-hackers по дате отправления: