Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Mahendra Singh Thalor <mahi6run@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-02-04T16:06:24Z
Lists: pgsql-hackers
Attachments
On Thu, Feb 04, 2021 at 08:34:13PM +0530, Mahendra Singh Thalor wrote: > On Tue, 2 Feb 2021 at 09:51, Julien Rouhaud <rjuju123@gmail.com> wrote: > > > > On Mon, Feb 01, 2021 at 02:00:48PM -0300, Alvaro Herrera wrote: > > > So I think that I misspoke earlier in this thread when I said this is a > > > bug, and that the right fix here is to remove the Assert() and change > > > amcheck to match. > > > > I'm attaching a patch to do so. > > Thanks Julien for the patch. > > Patch looks good to me and it is fixing the problem. I think we can > register in CF. Thanks for looking at it! I just created an entry for the next commitfest. > > > > Changing the name may be overkill, but claryfing the hint bit usage in > > README.tuplock would definitely be useful, especially since the combination > > isn't always produced. How about adding something like: > > > > 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 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. > Make sense. Please can you update this? Sure, done in attached v2!
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