Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Mahendra Singh Thalor <mahi6run@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-02-04T16:37:50Z
Lists: pgsql-hackers
Attachments
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.
Commits
-
Reinstate HEAP_XMAX_LOCK_ONLY|HEAP_KEYS_UPDATED as allowed
- bf518fefacc7 10.17 landed
- 8deb6b38dc4c 14.0 landed
- 28f4b61083b2 13.3 landed
- 2796ae2ad253 12.7 landed
- 2583917075ae 11.12 landed
- 0ccebe779dc0 9.6.22 landed